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METHODS OF PROVIDING DATA SERVICES OVER DATA NETWORKS 
AND RELATED DATA NETWORKS, DATA SERVICE PROVIDERS, 
ROUTING GATEWAYS AND COMPUTER PROGRAM PRODUCTS 

RELATED APPLICATION 
This application claims the benefit of and priority to U. S. Provisional Patent 
Application No. 60/470,650, filed May 15, 2003, the disclosure of which is hereby 
incorporated herein by reference as if set forth in its entirety. 

5 

FIELD OF THE INVENTION 
The present invention relates to communication networks, and, more 
particularly, to managing Quality of Service (QoS) in communication networks. 

1 0 BACKGROUND OF THE INVENTION 

The Internet is a decentralized network of computers that can communicate 
with one another via the internet protocol (IP). Although the Internet has its origins in 
a network created by the Advanced Research Project Agency (ARPA) in the 1960's, it 
has only recently become a worldwide communication medium. To a large extent, 

15 the explosive growth in use and traffic over the Internet is due to the development in 
the early 1990's of the worldwide Web (WWW), which is one of several service 
facilities provided on the Internet. Other facilities include a variety of communication 
services such as electronic mail, telnet, Usenet newsgroups, internet relay chat (IRC), 
a variety of information search services such as WAIS and Archie, and a variety of 

20 information retrieval services such as FTP (file transfer protocol) and Gopher. 

The WWW is a client-server based facility that includes a number of servers 
(computers connected to the Internet) on which Web pages or files reside, as well as 
clients (Web browsers), which interface the users with the Web pages. Specifically, 
Web browsers and software applications send a request over the WWW to a server 

25 requesting a Web page identified by a Uniform Resource Locator (URL) which notes 
both the server where the Web page resides and the file or files on that server which 



2 



Attorney Docket No. 9400-50 



5 make up the Web page. The server then sends a copy of the requested file(s) to the 
Web browser, which in turn displays the Web page to the user. 

The topology of the WWW can be described as a network of networks, with 
providers of network service called Network Service Providers, or NSPs. Servers that 
provide application-layer services as previously described may be described as 
10 Application Service Providers (ASPs). Sometimes a single service provider does both 
functions within a single business 

In recent years, broadband access technologies, such as digital subscriber line 
(DSL), cable modems, asynchronous transfer mode (ATM), and frame relay have 
facilitated the communication of voice, video, and data over the Internet and other 
1 5 public and private networks. Because broadband technologies are typically deployed 
by a single transport service provider, like a Regional Bell Operating Company 
(RBOC), their Regional and Access Networks (RAN) are often shared by many NSPs 
and ASPs offering services that range from Internet access and VPN access to Voice 
over IP, Video on Demand, and Gaming. Up until recently, a given Customer 
20 Premises Network (CPN) would have been connected to a single service, provider in a 
generic way, however a new standard for RAN service (DSL Forum TR-059) 
provides a RAN architecture that allows simultaneous access to multiple NSPs and 
ASPs and for differentiating the data transport service provided by a RAN to these 
service providers. 

25 Moreover, broadband access technology has allowed service providers to 

expand their content and service offerings to both business and home users. For 
example, a user may subscribe to multiple services or applications, such as voice 
service, Internet access service, a video service, a gaming service, etc. from one or 
more service providers. These services and/or applications may be delivered over a 

30 single network connection, such as a DSL line. Unfortunately, with multiple new 
connectivity options and applications that require specific characteristics from the 
network, there is also a need to establish priorities and bandwidth allocation among 
multiple services and/or applications so as to customize the content delivery 
according to the users' and/or providers' preferences. 

35 

SUMMARY OF THE INVENTION 
According to embodiments of the present invention, methods may be provided 
for operating a data network between a routing gateway for a subscriber and a data 
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5 service provider providing a data service. More particularly, methods may include 
receiving from the data service provider an identification of the routing gateway, an 
identification of the data service provider, and data flow characteristics of the data 
service for a session of the routing gateway using the data service provided by the 
data service provider. Responsive to receiving the identification of the routing 
1 0 gateway, the identification of the data service provider, and the data flow 

characteristics for the data service, the data flow characteristics of the data service for 
the routing gateway may be saved at the data network and forwarded to the routing 
gateway. 

More particularly, the routing gateway may be coupled to the data network via 

15 a digital subscriber line and the identification of the routing gateway may be a digital 
subscriber line identification. In addition, the data flow characteristics of the data 
service may include a bandwidth characterization for the data service and a priority 
characterization for the data service. Moreover, an authorization code may be 
received for the data service, and the authorization code may be validated before 

20 saving the data flow characteristics. 

Saving the data flow characteristics at the data network may include creating 
an application flow control record for the routing gateway, and the data flow 
characteristics may be saved at first and second databases within the data network. 
More particularly, the first database may be associated with a concentrator and the 

25 second database may be associated with a service manager. 

Before receiving the data flow characteristics, a request may be received from 
the routing gateway for a session using the data service provided by the data service 
provider, and the request from the routing gateway may be forwarded to the data 
service provider. In addition, an interconnection may be provided between the 

30 routing gateway and the data service provider in accordance with the data flow 
characteristics to thereby support a session of the routing gateway using the data 
service provided by the data service provider. 

Once the session is over, the data flow characteristics saved at the data 
network for the session of the routing gateway using the data service may be deleted, 

35 and the interconnection may be terminated between the routing gateway and the data * 
service provider to thereby terminate the session of the routing gateway using the data 
service. In addition, a request may be received from the data service provider to 
delete the data flow characteristics for the session of the routing gateway using the 
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5 data service, wherein the data flow characteristics are deleted responsive to receiving 
the request before deleting the data flow characteristics. 

According to additional embodiments of the present invention, methods may 
be provided for operating a data service provider providing a data service over a data 
network to a routing gateway for a subscriber using the data service. More 
10 particularly, methods may include transmitting to the data network an identification of 
the routing gateway, an identification of the data service provider, and data flow 
characteristics of the data service for a session with the routing gateway using the data 
service. The data service may be provided over the data network and routing gateway 
in accordance with the data flow characteristics transmitted to the data network to 
1 5 support a data session of the data service provider with the routing gateway. 

Moreover, the routing gateway may be coupled to the data network via a 
digital subscriber line, and the identification of the routing gateway may be a digital 
subscriber line identification. In addition, the data flow characteristics of the data 
service may include a bandwidth characterization for the data service and a priority 
20 characterization for the data service. 

An authorization code for the data service may be transmitted to the data 
service provider, and a validation of the authorization code may be received from the 
data network before providing the data service. Moreover, a request may be received 
from the routing gateway for a session using the data service before transmitting the 
25 identification of the routing gateway, the identification of the data service provider, 
and the data flow characteristics. 

In addition, a request may be transmitted to the data service provider to delete 
the data flow characteristics for the session of the routing gateway using the data 
service. After transmitting the request to delete the data flow characteristics, the data 
30 service may be terminated over the data network and routing gateway. 

According to yet additional embodiments of the present invention, methods 
may be provided for operating a routing gateway providing subscriber use of a data 
service provided by a data service provider over a data network. The methods may 
include receiving data flow characteristics of the data service for a session of the 
35 routing gateway using the data service provided by the data service provider. Access 
to the data service may be provided over the data network in accordance with the data 
flow characteristics received from the data network to support a data session with the 
data service provider. 
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More particularly, the routing gateway may be coupled to the data network via 
a digital subscriber line. Moreover, the data flow characteristics of the data service 
may include a bandwidth characterization for the data service and a priority 
characterization for the data service. In addition, a request may be transmitted to the 
data service provider for a session using the data service provided by the data service 
provider before receiving the data flow characteristics. 

According to still additional embodiments of the present invention, a data 
network may provide a data connection between a routing gateway for a subscriber 
and a data service provider providing a data service. The data network may include a 
first transceiver configured to receive from the data service provider an identification 
of the routing gateway, an identification of the data service provider, and data flow 
characteristics of the data service for a session of the routing gateway using the data 
service provided by the data service provider. A memory may be configured to save 
the data flow characteristics of the data service for the routing gateway at the data 
network responsive to receiving the identification of the routing gateway, the 
identification of the data service provider, and the data flow characteristics for the 
data service. A second transceiver may be configured to forward the data flow 
characteristics of the data service to the routing gateway. 

According to more embodiments of the present invention, a data service 
provider may provide a data service over a data network to a routing gateway for a 
subscriber using the data service. The data service provider may include a transceiver 
configured to transmit to the data network an identification of the routing gateway, an 
identification of the data service provider, and data flow characteristics of the data 
service for a session with the routing gateway using the data service. The transceiver 
may be further configured to provide the data service over the data network and 
routing gateway in accordance with the data flow characteristics transmitted to the 
data network to support a data session of the data service provider with the routing 
gateway. 

According to yet more embodiments of the present invention, a routing 
gateway may provide subscriber use of a data service provided by a data service 
provider over a data network. In particular, the routing gateway may include a 
transceiver configured to receive data flow characteristics of the data service for a 
session of the routing gateway using the data service provided by the data service 
provider. The transceiver may be further configured to provide access to the data 
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5 service over the data network in accordance with the data flow characteristics 
received from the data network to support a data session with the data service 
provider. 

According to still more embodiments of the present invention, a computer 
program product may be configured to operate a data network between a routing 
10 gateway for a subscriber and a data service provider providing a data service. The 
computer program product may include a computer useable storage medium having 
computer-readable program code embodied in the medium. More particularly, the 
computer-readable program code may include computer-readable program code that 
is configured to receive from the data service provider an identification of the routing 
15 gateway, an identification of the data service provider, and data flow characteristics of 
the data service for a session of the routing gateway using the data service provided 
by the data service provider. The computer-readable program code may also include 
computer-readable program code that is configured to save the data flow 
characteristics of the data service for the routing gateway at the data network 
—..20 responsive to receiving the identification of the routing gateway, the identification of 
the data service provider, and the data flow characteristics for the data service. In 
addition, the computer-readable program code may include computer-readable 
program code that is configured to forward the data flow characteristics of the data 
service to the routing gateway. 
25 According to additional embodiments of the present invention a computer 

program product may be configured to operating a data service provider providing a 
data service over a data network to a routing gateway for a subscriber using the data 
service. The computer program product may include a computer useable storage 
medium having computer-readable program code embodied in the medium. The 
30 computer-readable program code may include computer-readable program code that 
is configured to transmit to the data network an identification of the routing gateway, 
an identification of the data service provider, and data flow characteristics of the data 
service for a session with the routing gateway using the data service. The computer- 
readable program code may also include computer-readable program code that is 
35 configured to provide the data service over the data network and routing gateway in 
accordance with the data flow characteristics transmitted to the data network to 
support a data session of the data service provider with the routing gateway. 
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According to more embodiments of the present invention, a computer program 
product may be configured to operate a routing gateway providing subscriber use of a 
data service provided by a data service provider over a data network. The computer 
program product may include a computer useable storage medium having computer- 
readable program code embodied in the medium. The computer-readable program 
code may include computer-readable program code that is configured to receive data 
flow characteristics of the data service for a session of the routing gateway using the 
data service provided by the data service provider. The computer-readable program 
code may also include computer-readable program code that is configured to provide 
access to the data service over the data network in accordance with the data flow 
characteristics received from the data network to support a data session with the data 
service provider. 

Other systems, methods, and/or computer program products according to 
embodiments of the present invention will be or become apparent to one with skill in 
* the art upon review of the following drawings and detailed description. It is intended 
that all such additional systems, methods, and/or computer program products be 
included within this description, be within the scope of the present invention, and be 
protected by the accompanying claims. 

- BRIEF DESCRIPTION OF THE DRAWINGS 
Other features of the present invention will be more readily understood from 

the following detailed description of specific embodiments thereof when read in 

conjunction with the accompanying drawings, in which: 

FIG. 1 is a block diagram that illustrates a conventional digital subscriber line 

(DSL) network; 

FIG. 2 is a block diagram that illustrates communication between end users 
and an application service provider (ASP) and a network service provider (NSP) via a 
regional/access network; 

FIG. 3 is a block diagram that illustrates the regional/access network; 

FIG. 4 is a block diagram that illustrates a broadband remote access server 
(BRAS) and a routing gateway (RG) in a network; 

FIG. 5 is a block diagram that illustrates access session types in the network 
of FIG. 4 in accordance with some embodiments of the present invention; 
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5 FIG. 6 is a block diagram that illustrates traffic classification and queuing 

treatments in accordance with some embodiments of the present invention; 

FIG. 7 illustrates business model options for using bandwidth on a 
communication medium in accordance with some embodiments of the present 
invention; 

1 0 FIG. 8 is a block diagram that illustrates relationships between a subscriber, 

the RG 5 the regional/access network, an ASP, and an NSP; 

FIGS. 9 - 12 are block diagrams that illustrates a data architecture (model) for 
managing quality of service (QoS) in a network in accordance with some 
embodiments of the present invention; 
1 5 FIG. 13 is a block diagram that illustrates an application framework 

infrastructure for managing QoS in a network in accordance with some embodiments 
of the present invention; 

FIG. 14 illustrates a messaging flow for a service provider authentication 
scenario using the application framework infrastructure of FIG. 13 in accordance with 
20 some embodiments of the present invention; 

FIG. 15 illustrates a messaging flow for an application level bandwidth and 
QoS query scenario using the application framework infrastructure of FIG. 13 in 
accordance with some embodiments of the present invention; 

FIG. 16 illustrates a messaging flow for an application level bandwidth and 
25 QoS modification scenario using the application framework infrastructure of FIG. 13 
in accordance with some embodiments of the present invention; 

FIG. 17 illustrates a messaging flow for an application flow control record 
creation scenario using the application framework infrastructure of FIG. 13 in 
accordance with some embodiments of the present invention; 
30 FIG. 18 illustrates a messaging flow for an application flow control record 

deletion scenario using the application framework infrastructure of FIG. 13 in 
accordance with some embodiments of the present invention; 

FIG. 19 illustrates a messaging flow for a NSP Point-to-Point Protocol (PPP) 
session level bandwidth and QoS modification scenario using the application 
35 framework infrastructure of FIG. 13 in accordance with some embodiments of the 
present invention; 
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5 FIG. 20 illustrates a messaging flow for a ASP/NSP PPP session level 

bandwidth and QoS query scenario using the application framework infrastructure of 
FIG. 13 in accordance with some embodiments of the present invention; 

FIG. 21 is a block diagram that illustrates a turbo button architecture using the 
application framework infrastructure of FIG. 13 in accordance with some 
1 0 embodiments of the present invention; 

FIG. 22 is an event diagram that illustrates operations of the turbo button 
architecture of FIG. 21 in accordance with some embodiments of the present 
invention; 

FIG. 23 is a block diagram that illustrates a video conferencing architecture 
1 5 using the application framework infrastructure of FIG. 13 in accordance with some 
embodiments of the present invention; 

FIGS. 24 and 25 are event diagrams that illustrate operations of the video 
conferencing architecture of FIG. 23 in accordance with some embodiments of the 

present invention; 

20 FIG. 26 is a block diagram that illustrates traffic classification and queuing 

treatments for the video conferencing service in accordance with some embodiments 
of the present invention; 

FIG. 27 is a block diagram that illustrates operations of a video conferencing 
architecture in accordance with some embodiments of the present invention; 
25 FIG. 28 is a diagram that illustrates network topologies for supporting gaming 

applications in accordance with some embodiments of the present invention; 

FIG. 29 is a block diagram that illustrates a gaming architecture using the 
application framework infrastructure of FIG. 13 in accordance with some 
embodiments of the present invention; 
30 FIG. 30 is a block diagram that illustrates traffic classification and queuing 

treatments for the gaming service in accordance with some embodiments of the 
present invention; 

FIG. 31 is an event diagram that illustrates operations of the gaming 
architecture of FIG. 29 in accordance with some embodiments of the present 
35 invention; and 

FIG. 32 is a block diagram of network service providers in accordance with 
some embodiments of the present invention. 

10 



Attorney Docket No. 9400-50 



5 FIGS. 33-35 axe flow charts illustrating operations of data networks, 

application service providers, and routing gateways according to embodiments of the 
present invention. 

DETAILED DESCRIPTION OF EMBODIMENTS 

10 While the invention is susceptible to various modifications and alternative 

forms, specific embodiments thereof are shown by way of example in the drawings 
and will herein be described in detail. It should be understood, however, that there is 
no intent to limit the invention to the particular forms disclosed, but on the contrary, 
the invention is to cover all modifications, equivalents, and alternatives falling within 

15 the spirit and scope of the invention as defined by the claims. Like reference numbers 
signify like elements throughout the description of the figures. 

The present invention may be embodied as systems, methods, and/or computer 
program products. Accordingly, the present invention may be embodied in hardware 
and/or in software (including firmware, resident software, micro-code, etc.). 

20 Furthermore, the present invention may. take the form of a computer program product 
on a computer-usable or computer-readable storage medium having computer-usable 
or computer-readable program code embodied in the medium for use by or in 
connection with an instruction execution system. In the context of this document, a 
computer-usable or computer-readable medium may be any medium that can contain, 

25 store, communicate, propagate, or transport the program for use by or in connection 
with the instruction execution system, apparatus, or device. 

The computer-usable or computer-readable medium may be, for example but 
not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or 
semiconductor system, apparatus, device, or propagation medium. More specific 

30 examples (a nonexhaustive list) of the computer-readable medium would include the 
following: an electrical connection having one or more wires, a portable computer 
diskette, a random access memory (RAM), a read-only memory (ROM), an erasable 
programmable read-only memory (EPROM or Flash memory), an optical fiber, and a 
portable compact disc read-only memory (CD-ROM). Note that the computer-usable 

35 or computer-readable medium could even be paper or another suitable medium upon 
which the program is printed, as the program can be electronically captured, via, for 
instance, optical scanning of the paper or other medium, then compiled, interpreted, or 
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otherwise processed in a suitable manner, if necessary, and then stored in a computer 
memory. 

Embodiments of the present invention are described herein in the context of 
digital subscriber line (DSL) technology for purposes of illustration. It will be 
understood that the present invention is not limited to DSL technology. Indeed, other 
communication technologies and/or network configurations, such as, but not limited 
to, asynchronous transfer mode (ATM), frame relay, hybrid fiber coax (HFC), 
wireless broadband, and/or Ethernet may also be used in other embodiments of the 
present invention. In general, the present invention is not limited to any 
communication technology and/or network configuration, but is intended to 
encompass any technology and/or network configuration capable of carrying out 
operations described herein. Embodiments of the present invention are also described 
herein in the context of managing quality of service (QoS). As used herein, QoS 
includes, but is not limited to, treatment applied to an access session, application flow, 
and/or packet with respect to scheduling a resource, bandwidth allocation, and/or 
delivery target in an individual element or across an endrto-end system. 

The detailed description of embodiments of the present invention is organized 
as follows: 

1. Overview - 

2. Introduction ....... ■-. 

2.1 Purpose and Scope 

2.2 Key Terms 

3. Review of TR-059 Concepts 

3 . 1 Network Service Provider Network 
3.1.1 Description 

3 .2 Application Service Provider Network 

3.2.1 Description 

3.2.2 Capabilities 

3.3 Regional Access Network 

3.3.1 Broadband Remote Access Server 

3.3.2 Access Network 

3.3.3 Access Node 

3 .4 Evolution of the DSL Network 
3.4.1 Access Session Types 
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5 4. QOS Capabilities of the Application Framework 

4.1 General Approach 

4.2 Classification 

4.3 Business Models for Supporting Concurrent NSP and ASP Access 
Sessions 

10 4.3.1 Simple Bandwidth Partitioning 

4.3.2 Priority and Dynamic Bandwidth Sharing 

4.4 Considerations Associated with this Approach 

4.4.1 Static Classifiers 

4.4.2 Queue Structure 
15 5 . Reference Data Model 

5.1 Subscriber Maintained Data 

5.2 Routing Gateway 

5.3 Regional/ Access Network 

5.4 Application Service Provider 

20. 5.5 Network Service Provider _ - 

6. Reference Interface Specification and Detailed Message Flow 

6. 1 Interface Between RG and Regional/Access Network 

6.2 Interface Between Regional/Access Network and ASP 

6.3 Interface Between Regional/Access Network and NSP-. - 
25 6.4 Application Framework Infrastructure 

6.4.1 Framework Infrastructure Element Functional Description 

6.4.2 DSL Service Messaging Flow 

7. Future Capabilities of the Application Framework 

8. Example Use Scenario - Turbo Button 

30 9. Example Use Scenario - Video Conferencing 

10. Example Use Scenario - Gaming 

1 1 . Application Flow Control Data 

1. Overview 

35 This document defines a common application framework built on top of the 

DSL Forum TR-059 reference architecture that can be used in a common way to 
enable service providers to leverage bandwidth and QoS capabilities in the 
Regional/ Access Network. This framework comprises an interface specification and 
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5 associated data model and mechanisms to control the QoS and bandwidth capabilities 
defined in TR-05 9. A common interface for Application Service Providers (ASPs) 
and Network Service Providers (NSPs) to leverage may reduce development costs and 
time to market. This interface defines a mechanism for applications to request IP QoS 
and bandwidth from the DSL Regional/ Access network. 

10 2. Introduction 

2.1 Purpose and Scope 

Recent work in the DSL Forum has documented a reference architecture, DSL 
Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services 
1 (TR-059) 5 with the purpose of defining a common way of supporting enhanced IP 

15 applications by enabling IP QoS and bandwidth management capabilities. TR-05 9 
defines a common deployment architecture, set of interface specifications, and 
fundamental network element requirements. The architecture and requirements are 
largely "transport or network" layer focused. It may be useful to complement this 
work by defining a common higher-layer framework that leverages the capabilities of 

20 TR-05 9 and that can be used by application service providers (ASP) as they-develop....: 
and deploy applications. 

This document defines a common application framework built on top of the 
TR-05 9 reference architecture that can be used in a common way to enable service 
providers to leverage bandwidth and QoS capabilities in the Regional/Access : .• . 

25 Network. This framework comprises an interface specification and associated data 
model and mechanisms to control the QoS and bandwidth capabilities defined in TR- 
059. A common interface for ASPs and NSPs to leverage may reduce development 
costs and time to market. This interface defines a mechanism for applications to 
request IP QoS and bandwidth from the DSL Regional/Access network. 

30 Specifically, the application framework is based on the capabilities defined in 

phase 2 of TR-059. Therefore, the framework defined here assumes that the 
capabilities of the access node in the Regional/ Access network will remain largely 
unchanged, but does leverage a policy approach for provisioning the BRAS and 
Routing Gateway (RG) to manage IP flows appropriately. As real-time signaling 

35 capabilities become available this framework may be modified to support these 
capabilities. In defining the framework and providing details of its use, this 
document also intends to demonstrate that capabilities defined (here and in TR-059) 
are sufficient to support a reasonable set of applications. 
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Services that span Regional/ Access networks and require inter- 
Regional/Access network communication are generally not described herein as part of 
this framework. Support of these services is possible if handled at the application 
layer where an ASP communicates to each Regional/Access network to establish 
bandwidth and QoS for a service. 
2.2 Key Terms 
The following definitions apply for the purposes of this document: 



Access Network 



Access Node 



The Access Network encompasses the elements of 
the DSL network from the NID at the customer 
premises to the BRAS. This network typically 
includes one or more Access Node type and often 
an ATM switching function to aggregate them. 

The Access Node contains the ATU-C, which 
terminates the DSL signal, and physically can be a 
DSLAM, Next Generation DLC (NG-DLC), or a 
Remote Access Multiplexer (RAM). A DSLAM 
hub can be used in a central office to aggregate 
traffic from multiple remote physical devices, and 
is considered logically to be a part of the Access 
Node. When the term "DSLAM" is used in "this 
document, it is intended to very specifically refer to 
a DSLAM, and not the more generic Access Node. 
The Access Node provides aggregation capabilities 
between the Access Network and the Regional 
Network. It is the first point in the network where 
traffic on multiple DSL lines will be aggregated 
onto a single network. 

The set of packets associated with a particular 
application (e.g., video conferencing session, VoIP 
call, etc.). 

A common reference data model and interface 
specification built on top of the TR-059 reference 
architecture that can be used in a common way to 
enable service providers to leverage bandwidth and 
QoS capabilities in the Regional/Access Network. 

Auto Configuration Server (ACS) A data repository that allows the Regional/Access 

network to provide configuration information to 
Routing Gateways (RG) in Customer Premises 

Broadband Remote Access Server (BRAS) The BRAS is the aggregation point 

for the subscriber traffic. It provides aggregation 
capabilities (e.g., IP, PPP, ATM) between the 
Regional/Access Network and the NSP or ASP. 
Beyond aggregation, it is also the injection point 



Application Flow 



Application Framework 
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Core Network 



10 



Downstream 
Edge Network 



15 



for policy management and IP QoS in the 
Regional/Access Networks. 

The center core of the Regional Network. The 
functions contained herein are primarily transport 
oriented with associated switching or routing 
capabilities enabling the proper distribution of the 
data traffic. 

The direction of transmission from the ATU-C 
(Access Node) to the ATU-R (modem). 

The edge of the Regional Network. The Edge 
Network provides access to various layer 2 
services and connects to the Regional Network 
core enabling the distribution of the data traffic 
between various edge devices. 



20 



25 



Loop 



Many-to-Many Access Sessions 



Regional Network 
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Regional/Access Network 



40 



Routing Gateway 



Rate Limit 



45 



A metallic pair of wires running from the 
customer's premises to the Access Node. 

The ability for multiple individual users or 
subscribers, within a single premises, to 
simultaneously connect to multiple NSPs and 
ASPs. ~ - 

The Regional Network interconnects the Network 
Service Provider's network and the Access 
Network. A Regional Network for DSL connects 
to the BRAS, which is technically both in the 
Regional Network and in an Access Network. 
Typically, more than one Access Network is 
connected to a common Regional Network. The 
function of the Regional Network in this document 
goes beyond traditional transport, and may include 
aggregation, routing, and switching. 

The Regional and Access Networks - grouped as 
and end-to-end QoS domain and often managed by 
a single provider. The follow functional elements 
are contained in this network: Access Node, 
BRAS, and the ACS. 

A customer premises functional element that 
provides IP routing and QoS capabilities. It may be 
integrated with or be separate from the ATU-R. 

A means to limit the throughput of a particular PPP 
session or application flow by either buffering 
(shaping) or dropping (policing) packets above a 
specified maximum data rate. The term bandwidth 
is used interchangeably with the concept of rate 
limiting. The bandwidth allocated to a PPP 
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session or application is determined by the rate 
limit applied. 

Session is typically an overloaded term. In this 
document it is intended to reference a PPP access 
session rather than a particular application flow. 

Used to refer to the person that is billed for a 
service, like NSP access service or ASP services. 
The subscriber is considered the primary user of 
the service (see the definition of ''user" below) and 
is the main account contact. The subscriber to an 
NSP access is referred to as a Network Subscriber 
and the subscriber to an application is referred to as 
an Application Subscriber. 

The direction of transmission from the ATU-R 
(modem) to the ATU-C (Access Node). 

The person or entity that receives the benefit of 
a given service. The user may or may not be the 
subscriber of the service. A subscribed service 
has one or more users associated with the 
subscriber. 

3. Review of TR-059 Concepts 

To provide a common reference for the application framework, an 
3.0 architectural view of the DSL network is provided. The text in this section is taken 

from TR-059 and provides a high level overview. For a more complete description 

refer to TR-059. FIG. 1 illustrates the current state of deployed DSL networks. 

Boxes in the figures represent functional entities - networks and logical components 

rather than physical elements. 
35 This traditional architecture is centered on providing service to a line or a 

loop. It is desired, however, to be able to provide services that are user-specific. 

Additionally, more than one subscriber can be present at the same premises and share 

a single loop. TR-059 describes a slightly more complex situation, and hides the 

common complexity shared with FIG. 2. 
40 FIG. 2 illustrates the components of a DSL access-based broadband network. 

FIG. 2 indicates ownership of the components by different providing organizations. 

Boxes in the figures represent functional entities - networks and logical components 

rather than physical elements. 
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This model illustrates an architecture that provides services that are user- 
specific, i.e., more than one subscriber can be present at the same premises and share 
a single loop. Note that FIG. 2 shows many-to-many access through a common 
Regional/ Access network. It is used to simultaneously provide an Application 
Servicei between an ASP Network] and Useri at the same time and over the same U 
interface as it supports a Network Service 2 between NSP Network 2 and User 2 . 
3.1 Network Service Provider Network 

3-1.1 Description 
The Network Service Provider (NSP) is defined as a Service Provider that 
requires extending a Service Provider-specific Internet Protocol (IP) address. This is 
the typical application of DSL service today. The NSP owns and procures addresses 
that they, in turn, allocate individually or in blocks to their subscribers. The 
subscribers are typically located in Customer Premises Networks (CPNs). The NSP 
service may be subscriber-specific, or communal when an address is shared using 
Network Address Port Translation (NAPT) throughout a CPN. This relationship 
among. the NSP, A10-NSP interface, and Regional/Access Network is shown in FIG. 
2. NSPs typically provide access to the Internet, but may also provide access to a 
walled garden, VPN, or some other closed group or controlled access network. L2TP 
and IP VPNs are typical A10-NSP interface arrangements. 

The capabilities of the NSP may include, but are not limited to, for example: 
authenticating network access between the CPN and the NSP network; assignment of 
network addresses and IP filters; assignment of traffic engineering parameters; and/or 
customer service and troubleshooting of network access problems 
3.2 Application Service Provider Network 

3.2.1 Description 
The Application Service Provider (ASP) is defined as a Service Provider that 
uses a common network infrastructure provided by the Regional/Access Network and 
an IP address assigned and managed by the Regional Network Provider. This is a 
new type of DSL service. The Regional Network Provider owns and procures 
addresses that they, in turn, allocate to the subscribers. ASPs then use this common 
infrastructure to provide application or network services to those subscribers. For 
example, an ASP may offer gaming, Video on Demand, or access to VPNs via IPsec 
or some other IP-tunneling method. The ASP service may be subscriber-specific, or 
communal when an address is shared using NAPT throughout a Customer Premises 
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Network (CPN). It is envisioned that the ASP environment will have user-level rather 
than network-access-level identification, and that a common Lightweight Directory 
Access Protocol (LDAP) directory will assist in providing user identification and 
preferences. Logical elements used by ASPs typically include routers, application 
servers, and directory servers. The relationship between the ASP Network, the A10- 
ASP interface, and the Regional Network is shown in FIG. 2. 
3.2.2 Capabilities 

The capabilities of the ASP may include, but are not limited to, for example: 
authenticating users at the CPN; assignment of QoS to service traffic; customer 
service and troubleshooting of network access and application-specific problems; 
and/or ability to determine traffic usage for accounting purposes and billing. 

3.3 Regional Access Network 

The Regional/Access Network comprises the Regional Network, Broadband 
Remote Access Server, and the Access Network as shown in FIG. 3. Its primary 
function is to provide end-to-end data transport between the customer premises and 
.the NSP.or-ASP. The Regional/Access Network may also provide higher layer 
functions, such as QoS and content distribution. QoS may be provided by tightly 
coupling traffic-engineering capabilities of the Regional Network with the capabilities 
of the BRAS. 

3.3.1 Broadband Remote Access Server 

The BRAS performs multiple functions in the network. Its most basic function is 
to provide aggregation capabilities between the Regional/Access Network and the 
NSP/ASP. For aggregating traffic, the BRAS serves as a L2TP Access Concentrator 
(LAC), tunneling multiple subscriber Point-to-Point Protocol (PPP) sessions directly to an 
NSP or switched through a L2TS. It also performs aggregation for terminated PPP 
sessions or routed IP session by placing them into IP VPNs. The BRAS also supports 
ATM termination and aggregation functions. 

Beyond aggregation, the BRAS is also the injection point for providing policy 
management and IP QoS in the Regional and Access Networks. The BRAS supports the 
concept of many-to-many access sessions. Policy information can be applied to 
terminated and non-terminated sessions. For example, a bandwidth policy may be applied 
to a subscriber whose Point-to-Point (PPP) session is aggregated into an L2TP tunnel and 
is not terminated by the BRAS. Sessions that terminate on (or are routed through) the 
BRAS, however, can receive per flow treatment because the BRAS has IP level awareness 
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5 of the session. In this model, both the aggregate bandwidth for a customer as well as the 
bandwidth and treatment of traffic per-application can be controlled. 
3.3.2 Access Network 

The Access Network refers to the network between the ATU-R and the BRAS 
including the access node and any intervening ATM switches. 
10 3.3.3 Access Node 

The Access Node provides aggregation capabilities between the Access 
Network and the Regional Network. It is the first point in the network where traffic 
on multiple DSL lines will be aggregated onto a single network. Traditionally the 
Access Node has been primarily an ATM concentrator, mapping PVCs from the 
1 5 ATU-R to PVCs in the ATM core. It has also shaped and policed traffic to the service 
access rates. 

As described in TR-059, the responsibility of policing ATU-R to ATU-C 
PVCs to the subscribed line rate is moved from the Access Node to the BRAS to 
establish additional bandwidth on the DSL line for additional services. The Access 
20 Node sets W line rate for each PVC at the synch rate (or slightly less) of the ATU-R 
and ATU-C. This will make the maximum amount of subscriber bandwidth available 
for services. The BRAS polices individual sessions/flows as required to their required 
rates and also performs the dynamic changes when bandwidth-on-demand services are 
applied. 

25 3.4 Evolution of the DSL Network 

Phases 1 and 2 of TR-059 introduce the capability to change the 
Regional/Access network from an IP unaware layer 2 network to a network that 
leverages IP awareness in key elements to enable IP QoS and more efficient and 
effective use of bandwidth. These key IP aware elements are the BRAS and the RG 

30 as shown in FIG. 4. 

FIG. 4 represents a paradigm shift in that the BRAS and the RG are now 
responsible for managing the traffic flow through the network. By enabling these 
devices to accept policy rules at subscriber session and application levels, IP flows 
can be managed in a more flexible and "dynamic" manner than previously possible. 

35 The BRAS is responsible for managing IP traffic in the downstream direction such 

that traffic is scheduled according to priority and in a way that ensures that congestion 
in the downstream network is reduced (i.e., hierarchical scheduling). The RG 
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5 similarly, manages the scheduling of traffic in the upstream direction based on the 
priority of the session and/or application. Given that the RG cannot be trusted, the 
BRAS performs a policing function to ensure the upstream bandwidth in the access 
network is utilized appropriately. Note that the priority and bandwidth policies can be 
applied at the PPP session and or application levels; therefore, there is flexibility in 
1 0 how traffic is treated in the network. 

3.4.1 Access Session Types 

The architecture also evolves the types and number of access sessions 
(specifically PPP sessions) that a subscriber would typically establish to a service 
provider. Where previously there had been just one access session to an ISP, there are 

1 5 now multiple access sessions with three basic types: 

Community NSP - Shown in FIG. 5 as the solid line between the RG and 
NSPi, this type of access session is established between an RG and an NSP. It is 
called the Community NSP connection because all the devices within the Customer 
Premises Network share the connection to the NSP using the Network Port Address 

20 Translation ^(NP AT) feature of the.RG. Because the Community NSP connection is 
given the Default Route at the RG there can typically be only one. This connection is 
typically set up to an ISP to provide Internet access to all the devices in the Customer 
Premises Network. This PPP session may terminate on the BRAS or may pass 
through the BRAS in tact and be placed into a L2TP tunnel to the NSP. 

25 Personal NSP - Shown in FIG. 5 as the dashed line between Useri and NSP 2 , 

this type of access session is established between a device within the Customer 
Premises Network and an NSP. It passes through the RG at the Ethernet (PPPoE) 
level. It is called the Personal NSP connection because only the device within the 
Customer Premises Network from which the connection was established can access 

30 the NSP. This connection may avoid using the NPAT feature of the RG. This 
connection is typically set up to an ISP or a corporation to provide private or 
personalized access, or any access that cannot traverse the NPAT sharing mechanism 
at the RG. This PPP session may terminate on the BRAS or may pass through the 
BRAS in tact and be placed into a L2TP tunnel to the NSP. 

35 ASP - Shown in FIG. 5 as the dotted line between the RG and ASPi, this type 

of access session is established between an RG and the ASP network. It is typically a 
single connection that is shared by all the ASPs. Because the Community NSP 
connection is typically given the Default Route at the RG, the ASP connection must 
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5 provide the RG with a list of routes to the ASP network. Also because there is not a 
default route to the ASP network, it may not be possible to provide typical Internet 
access through the ASP connection. This connection is typically set up to the ASP 
network to provide application-specific and QoS-enabled access among all the 
applications in the ASP network and all the devices in the Customer Premises 
1 0 Network. This PPP session type may terminate on the BRAS so that per application 
flow treatment can be applied. 

4. QOS Capabilities of the Application Framework 
4.1 General Approach 

TR-059 describes a hierarchical scheduling approach leveraged by the BRAS 

1 5 to manage the downstream links between the BRAS and the RG. Similarly, it 

describes how the BRAS leverages policing techniques (including a random discard 
enhancement) to apply backpressure to the upstream source to minimize potential 
congestion in that direction. The application framework provides a mechanism for 
service providers to modify bandwidth and QoS. In particular embodiments of the 

20 present invention, to simplify the number of queues to be managed in the BRAS and 
RG, this framework assumes that only the ASP session has the ability to support per 
application flow treatment. In such embodiments, NSP access sessions can only be 
managed in terms of the aggregate bandwidth and priority with respect to other access 
sessions on the DSL line. .Because many ASPs share the ASP access session, the 

25 bandwidth and priority of the session is set by the Regional/ Access provider and 
typically cannot be modified by an ASP. The ASP can however modify the 
characteristics of specific applications within the ASP PPP session by assigning the 
application to a particular queue and treatment type. The BRAS and RG may 
schedule or police packets based on one or more of the following parameters: the 

30 priority of the access session; the current packet's relation to the rate limit of the 
access session; the priority of the application within the access session (only 
supported for the ASP PPP Session); and/or the current packet's relation to the rate 
limit of the application or queue, for example, an EF rate limit supported for the ASP 
PPP session. 

35 Network resources are typically not reserved in this model. Instead, traffic 

engineering policies and intelligent scheduling and policing of packets is leveraged to 
achieve aggregate QoS characteristics. Similarly, the Differentiated Services 
(Diffserv) model is leveraged as a way to classify, mark, and schedule packets. The 

22 



Attorney Docket No. 9400-50 

5 QoS approach that has been applied to the application framework assumes that these 
capabilities are in place and that QoS relationships can be viewed within a single 
subscribers DSL "connection" (ATM VC) between the BRAS and the RG. 

Further, if a pragmatic approach to providing QoS is taken, some additional 
simplifying assumptions can be made. It is expected that initially there will only be a 

10 small number of applications requiring QoS. The expected applications include VoIP, 
video conferencing, video on demand, and gaming. It is unlikely that the majority of 
DSL customers will subscribe to all of these services and expect to use them 
simultaneously. Rather, it is expected that only a small number of applications, (e.g., 
2 or 3) will need to be managed concurrently on a DSL line basis. The expected 

15 applications also imply a certain priority relationship among themselves. If while 
playing an Internet game a VoIP call comes in, it may be generally agreed that the 
VoIP session should take precedence over the gaming session (if finishing the game is 
more important, then the user can choose not to answer the call). As long as these 
assumptions hold true, then a small number of applications can be managed 

20 effectively with a small number of queues and a simple priority arrangement among 
them. As the number of applications requiring QoS increases, however, these 
assumptions may have to change and the QoS approach may need to evolve to support 
a finer granularity. 

The number of queues available for applications within the ASP PPP session 
25 is five, in accordance with some embodiments of the present invention. This may 

change over time, in accordance with other embodiments of the present invention, but 
initially the number of queues is likely to be small. Diffserv like treatment is assumed 
when describing the queue behaviors and can be classified as one expedited 
> forwarding (EF) queue, up to 3 assured forwarding (AF) queues or one best effort 
30 (BE) queue. The EF queue typically receives the highest priority and is typically 

served first. This queue type is defined for constant bit rate type servers. A rate limit 
associated with this queue is put in place so it should not be able to consume all the 
DSL line resources. This queue will likely be reserved for voice applications. 
AF queues are defined for traffic that is more variable in nature and would be 
35 inefficient to associate with a fixed amount of network resources (EF). Queues in this 
category could receive different levels of priority or could simply be used as an 
aggregate priority but each queue may have a different rate limit applied depending 
on the requirements of the application using that queue. To simplify the approach, the 
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5 framework initially assumes the later case where AF queue receive a "medium" 
priority treatment and the different queues are used to provide different bandwidth 
needs (i.e. rate limits). A BE queue is the default queue and has resources available to 
it only after packets that are in profile for the EF and AF queue are served. 

The approach to establishing QoS and bandwidth requirements in the network 

1 0 is one of provisioning rather than signaling. The BRAS and RG will be provisioned 
with the classifiers to identify flows and queue them appropriately. As a result the 
services that this model supports are services that fit more into a subscription model 
rather than an instantaneous establishment of service and QoS. This potential 
disadvantage, however, does not have to be apparent to the end users. Many services 

1 5 may require that the customer establish an account and perhaps even require the 

shipment of special hardware or software, for example, VoIP Phone, PC camera, and 
the like. During the time frame that the customer is establishing service with the 
ASP, the DSL network can be provisioned to support the service. It is important to 
note that the provisioning time lines are not expected to be in terms of days, but could 

20 be as small as a few minutes depending-on how the application framework is 
implemented. 

Given that a signaled approach to QoS is not included in the framework of 
certain embodiments of the present invention, real-time admission control cannot be 
accomplished at the network layer in such-embodiments. While it could be possible 

25 to block the subscription of a new service based on the current, subscribed services, 
such a model may be too restrictive because it does not allow the user to subscribe to 
two applications that they would not intend on using simultaneously. Instead, a strict 
priority relationship among the applications flows is used to manage simultaneous 
application interactions. Rate limits are also applied at the RG and BRAS so that no 

30 single application can consume all the subscriber's DSL resources and to provide 

some level of fairness. An example application relationship, in accordance with some 
embodiments of the present invention, is shown in FIG. 6 and Table 1. In this 
example, it is assumed that the NSP and PNSP sessions receive best effort treatment 
with respect to traffic that is in profile for the EF and AF queues in the ASP session. 

35 Other business models are possible as described in Section 4.3. 
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Signaling High Priority 1 00 Kbps SIP Proxy IP Address & SIP 

Bearer High Priority 100 Kbps Gateway IP Address & RTP 

Video Conf 

Control Stream High Priority 100 Kbps SIP Proxy IP Address & SIP 

Audio/Voice High Priority 1 00Kbps DSCP & MCU IP Address& RTP 

Video ^ Medium Priority 384Kbps DSCP & MCU IP Address & RTP 

Gaining Medium Priority 100k Gaming Server IP Address 

HTTP Low Priority None Default 

5 

Table 1 - Example Application Priority Relationship within the ASP Session 

FIG. 6 illustrates a queuing arrangement where there are five queues (EF, 
AFi, AF2, AF3, and BE) within the ASP session for per application treatment. In this 
arrangement, these queues can be characterized as high (EF), medium (AFs), and low 

10 priority (BE) treatment Table 1 illustrates that voice will receive strict priority over 
other applications. Rate limits can be applied to each of the applications to ensure 
that a single application cannot starve put all . other app>lications 3 but this requires 
dedicating a queue to each rate-limited application. Priority alone may not resolve all 
of the possible application interactions. -In the example. above, both the gaming and 

15 video conferencing video stream have the. same priority.. In the case that both 

applications are active they would compete o ver the first . I0Qk qf -bandwidth available 
to the medium priority class. The rate limit associated with the AF2 queue allows the 
video conferencing application to take precedence over the remaining resources up to 
its queue's rate limit. If the user experience for either the video stream or the game is 

20 unacceptable, the user will have to make their own admission control decision and 
pause or shut down the one they wish to have lower priority. 
4.2 Classification 

There are two basic levels of classification that need to be applied in the 
framework: The first level is at the PPP session level. Classification at this layer is 

25 accomplished through inspection of the Fully Qualified Domain Name (FQDN) used 
when the PPP session is initiated. The second level is at the application layer - 
according to flows. To provide an application flow with the proper scheduling 
treatment, it is desirable to easily classify the flow. Classification of application flow 
may be accomplished using the header fields of the IP or Ethernet Packet (e.g., IP 5 

30 tuple, DSCP, 802. Ip). Using the interface specified in Section 6, ASPs may 
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5 communicate the classification information that is used in the BRAS and RG. This 
same interface may be used to communicate the priority and desired bandwidth (rate 
limit) to be associated with the classifier. In certain embodiments of the present 
invention, this information is communicated at subscription time, and is not intended 
to be established dynamically on a per-flow basis. As a result in such embodiments, 

10 the classification information is expected to be static. The ASP may provide a well 
known IP address, protocol, and/or Port to be used for classification purposes. 

In particular embodiments of the present invention, within the customer 
premises network (CPN), the CPE will be assigned private IP addresses from the RG. 
When traffic leaves the CPN, the RG will perform NPAT enabling public routing of 

15 the packets. The use of private addresses presents two issues: Given that the CPE 

behind the RG will be using dynamic private addresses, they cannot be used as part of 
the classification parameters. Secondly, many applications require signaling 
messages to convey dynamic IP addresses and port numbers of media receivers in 
their payloads. Existing static IP/transport layer policies may not be adequate in ; 

20 supporting session endpoints separated by NAT and firewall entities. Therefore, - ... ./ ... , ■ 
Application Layer Gateway (ALG) capabilities may be required at the RG for opening 
and closing pinholes in the firewalls and maintaining the proper address translations • 
for dynamically created ports associated with flows created by session endpoints. - — 
Some considerations with regard to ALG capabilities are discussed in the next v-.z 

25 sections. 

The BRAS can associate the IP address or ATM PVC of the RG with a 
subscriber and then use the ASP's address to match the source or destination address 
of the packets to properly classify the flow. At the customer premises, the RG can 
match the ASP's address as the means of classifying the flow. Therefore, only the 

30 ASPs IP address (and possibly port and protocol identifier) may be required for the bi- 
directional flow to be classified correctly. 

Certain types of applications may require additional information to capture the 
flow. For these types of applications, the endpoints may need to provide additional 
classification information in the IP packet header by marking the diffserv code point. 

35 The use of diffserv code points (DSCP) may be standardized which may allow the 
application to intelligently mark packets based on the expected treatment in the 
network. DSCPs assigned by an untrusted entity can only be used after some edge 
device has performed a check on the classification of the packet to ensure that it was 
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5 marked correctly. The RG may not be considered a trusted element and, therefore, 
the BRAS may need to police any classification performed by the RG - rather than 
simply accepting the DSCP that was provided. Depending on the relationship to the 
ASP, the Regional/Access network may be able to trust packets marked by the ASP. 
If the ASP is not trusted, either the BRAS or some other edge device may need to 

10 police the DSCPs. 

4.3 Business Models for Supporting Concurrent NSP and ASP Access 
Sessions 

FIG. 7 illustrates several bandwidth relationships that can exist on an ADSL 
access loop. In FIG. 7, the outer circle represents the total bandwidth that is available 

15 within a virtual circuit on an ADSL line after the modems have been allowed to sync 
to a higher rate than is conventional. Within this total bandwidth there are two access 
sessions shown: an ASP Access Session and a NSP Access Session. The NSP Access 
Session, shown in light horizontal stripes, occupies a smaller space than the whole 
Virtual Circuit. This indicates that the NSP access session is not allowed to access the 

20 total bandwidth on the Virtual Circuit. Conventionally y the NSP Session and-the 

Virtual Circuit would have been the same bandwidth. By increasing the sync rate on 
the DSL modems, additional bandwidth is created that exceeds that which the NSP 
has purchased. 

The ASP access session has essentially the same set of bandwidth as the 
25 Virtual Circuit. This would indicate that some set of conditions exist where the ASP 
session could occupy all the bandwidth on the ADSL line. Several Applications are 
shown overlaid on the sessions and within the bandwidth limits assigned to the NSP 
and ASP. The NSP application (dark horizontal stripes) is a strict sub-set of the NSP 
Session and is using a large fraction of the NSPs allowed bandwidth. The three other 
30 applications, however, show three salient relationships and business models that can 
exist between applications in the ASP network and both applications as well as the 
access session for the NSP. These relationships will be described in the sections that 
follow. 

4.3.1 Simple Bandwidth Partitioning 

35 The first example is the Headroom Application and is shown in vertical 

stripes. This application is allowed to make use of only that bandwidth that the NSP 
could never access. In this type of model, a NSP is provided a dedicated amount of 
bandwidth on the access loop - even if there is not dedicated bandwidth through the 
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5 access network. In such an arrangement ASP applications (or additional NSP access 
sessions) would only receive bandwidth to which the modems could sync that was 
over and above the rate sold to the NSP. In this arrangement, if the sync rate were at 
or below the rate sold to the NSP, no additional applications or access sessions could 
be provided. This arrangement may be unnecessarily restrictive and may be difficult 
10 to implement. 

The second example is the Sharing Application (shown checkered). This 
application has access to all the bandwidth described by the headroom application, but 
also has access to additional bandwidth sold to the NSP, but not currently in use by 
applications in the NSP Session. A Sharing application can make use of all the 
1 5 bandwidth on the VC, but can only use the "NSP" bandwidth when the NSP session is 
not using it. Unlike the previous model, this application can receive bandwidth even 
when the sync rate is at or below the rate sold to the NSP. If the NSP applications are 
making use of all their bandwidth, however, then the result is similar to the 
arrangement described in the Headroom application. This arrangement could be ... 
20 described as work conserving, and may be used for simple bandwidth partitioning. 
4.3.2 Priority and Dynamic Bandwidth Sharing 
The third example is the Competing Application- (shown in transparent gray). 
In this example, the application may have access to some or all of the bandwidth used 
by the NSP and it may have access to that bandwidth with greater, equal, or lesser- . 
25 precedence than the NSP applications. Similarly, this application may also be able to 
pre-empt bandwidth that other ASP applications are attempting to use. This is the 
most complex arrangement, and the most flexible. A competing application can 
compete for the bandwidth that NSP applications are attempting to use. Several cases 
of competing applications exist: 
30 1 . The first case is when a competing application has the same precedence as that 

of the NSP application(s). In this case, bandwidth is shared fairly according to 
a typical algorithm, like round-robin, or Weighted Fair Queuing (WFQ). 
Also, inter-application congestion avoidance mechanisms, like those that are 
part of TCP can decide how applications would share bandwidth in this case. 
35 2. A second case is when a competing application has greater precedence than 

that of the NSP application(s). In this case, bandwidth is given to the 
competing application in strict priority - only "left-over" bandwidth is 
provided to the other applications. This is the highest QoS level, and may be 
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5 provided with an upper bound on the bandwidth that the application can 

obtain, i.e., a rate limit. If the application exceeds the upper bound, its traffic 
will be dropped. This case is the most applicable to a VoIP application 
because it provides very low latency and because VoIP is not bursty to the 
point that the rate limit would be exceeded. 

10 3. A third case is when a competing application has a combination of higher 

precedence and equal precedence. A rate, such as a committed information 
rate (CIR), is set and the application gets the same treatment as described in 
case 2 up to that rate. If the application bursts above CIR, then that traffic 
which bursts is treated differently; it must compete with the other applications 

15 as described in case 1. 

4. A fourth case is when a competing application has a combination of higher 
precedence and lower precedence. A rate, such as a CIR, is set and the 
application gets the same treatment as described in case 2 up to that rate. If 
the application bursts above CIR, then that traffic which bursts is treated - 

20 differently; it is treated like a sharing application - only receiving the leftover 

bandwidth that the NSP application does not use. 

5. A fifth case is when a competing application has a combination of higher 
precedence, equal precedence and a strict rate limit. A rate, such as a CIR, - 
and a second, higher rate, Peak information Rate (PIR), is set. The application 

25 gets the same treatment as described in case 3 up to the PIR rate. If the 

application bursts above PIR, then that traffic will be dropped. 

6. Finally, there is a case when a competing application has a combination of 
higher precedence, equal precedence and lower precedence. As in case 5, a 
rate, such as a CIR, and a second, higher rate, such as a PIR, is set. The 

30 application gets the same treatment as described in case 3 up to the PIR rate. 

However, if the application exceeds the PIR, then that traffic is treated like a 
sharing application - only receiving the bandwidth that the NSP does not use. 
These treatments can also be provided among ASP applications and with finer 
granularity among multiple applications. 
35 4.4 Considerations Associated with this Approach 

4.4.1 Static Classifiers 
The following issues may be considered when using static classifiers: 
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1 . There can only be one class of treatment per application. There is no sense of 
individual users within the residence using the same service, but desiring different 
levels of service. ' 

2. Dynamic, commutative peer-to-peer applications cannot be easily captured. 

3 . Applications with multiple flows between the same destinations cannot be easily 
differentiated. 

For applications like VoIP and video conferencing where the end points of a call may not 
be known a-priori 5 it is difficult to use a static classification scheme. 
Below are several approaches to resolve these issues: 

a. Force the application to some well-known IP address that can be used for 
classification purposes. This is true of a multipoint videoconference 
service that leverages a centralized (ASP provided) MCU or a VoIP call 
that is destined for a PSTN gateway or conference bridge. In both these 
cases, a static classifier can be used. This same approach could be 
leveraged for on-net or point-to-point video calls. These calls could be 
routed to utilize an MCU, conference bridge, or PSTN gateway even 
though they are not required for any other reason other than classification. . 
There are vendors in the marketplace that have developed proxy devices 
for this purpose. This may be less resource efficient, however, than . v . . 
allowing the calls to flow point-to-point. 

b. Classify based on protocol used. For example, classification based on the 
use of RTP could be used. Basing the classification on protocol alone, 
however, would enable other applications that use that same protocol to 
take advantage of QoS in the network without having to pay for it. 
Additionally, differentiation between application flows that use the same 
protocol may not be achieved (e.g., voice and video using RTP). 

c. Rely on the CPE to mark packets. In this case the IP phone or video 
conference application emits packets marked with the proper diffserv code 
point so that the RG and BRAS can classify based on that marking. Any 
application choosing to mark their traffic, however, would be able to take 
advantage of QoS in the network without having to pay for it. 

d. QoS aware Application Layer Gateway (ALG). Similar to the way ALGs 
have been developed for allowing signals to traverse NPAT and firewalls 
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5 by inspecting signaling messages, a QoS ALG may be created to inspect 

the signaling packets for SDP messages and to dynamically create 
classifiers during call setup. Given that initial signaling may be destined 
for a well known address, (SIP proxy) the ALG can be statically 
configured to treat all RTP flows set up using a given SIP proxy - 
1 0 regardless of the actual communicating peers. As the ALG inspects the 

packets to modify the RG's firewall rules, it can also be used to modify the 
RG's classification rules. This type of approach could be leveraged at the 
RG, where the number of sessions is small, but may present scaling issues 
if implemented in the BRAS. 
1 5 e. Establish the classification information at call set up. This may require 

complex real time signaling mechanisms to be in place in the network to 
modify classifiers at call establishment and teardown. 
Until a signaling approach is available, using an approach similar to that described 
in (a) appears to be the most reasonable from a technology and service offering 
. 20 perspective. A video conferencing ASP that does not provide centralized. Media Control 
Unit (MCU) capabilities may only add limited value above that which is already available 
in the market. In the near term, most VoIP calls will likely be destined for PSTN 
gateways, and this arrangement provides a simple way to classify. 

Differentiating applications with multiple flows between the same destinations, is 
25 typically seen within (but is not limited to) commutative services, like video conferencing. 
These applications typically have multiple flows (control/signaling, audio, and video) 
associated with a single application, and there may be a desire to treat them differently. As 
long as they use different well-known IP addresses or protocol types, then a static classifier 
can be used. Unfortunately, when the same protocol type is used (e.g., RTP for both audio 
30 and video) then there may not be a way to differentiate those streams if they are both 

destined for the same EP interface (e.g., MCU). Below are three approaches to resolve this 
issue: 

a. Require applications to use separate IP interfaces that expect differentiated 
treatment. An MCU, for example, could define one IP interface for video and 
35 another for audio. This would enable separate classification in the upstream and 

downstream direction in the RG and BRAS. Depending on the direction of the 
flow, either the source or destination can be used to match to the ASPs DP 
interfaces. 

31 



Attorney Docket No. 9400-50 

5 b. Rely on the application to mark packets. In this case, the videoconfererice 

application emits packets marked to the proper diffserv code point so that the RG 
and BRAS could classify based on that marking. As long as the packets are being 
transmitted to a well-known address, the classifier can use the combination of the 
DSCP and the destination IP. Given that there is a fixed IP address, no other 
1 0 applications would be able to utilize the QoS intended for this application. 

c. Rely on knowledge of the actual RTP ports used by each of the flows to enable 
different treatments. This can be accomplished by statically assigning ports using 
a QoS ALG function as described above, or through the use of a signaling 
protocol. 

15 4.4.2 Queue Structure 

As the number of applications requiring QoS increases, so does the complexity of 
managing them in the access network. Over time, as more and more ASPs deploy 
applications requiring QoS and bandwidth management, the likelihood that multiple 
applications will be running simultaneously within the CPN may increase. The 

20 ' " complexity of managing these applications in a small number of queues with only three 

levels of precedence may become increasingly difficult given that there may no longer be a 

" well-defined priority relationship among them. One approach would be to increase the 
number of queue types and behaviors. Diffserv defines four assured forwarding (AF) 

- : r " : i classes each with three levels of drop precedence. The addition of multiple AF classes to a 

25 strict priority class (EF) and a low priority class (BE) already defined in the application 

framework can provide more granularity in queue and application behavior. It is unlikely, 
however, that the number of queues can be scaled with the number of applications 
available. 

While a limited number of additional queues may be available, their expected 
30 behavior may become increasingly complex to describe. Unfortunately, to make use of 
these additional behaviors, applications must be able to define their requirements in a way 
that fits into this model. This becomes a challenge for two reasons: First, many 
applications do not understand that level of granularity and particularly will not understand 
what other applications will be vying for the DSL line resources. Secondly, describing the 
35 inter-queue or inter-application behavior to ASPs so they can make use of these 

capabilities becomes more difficult as the number of queues increases without strictly 
defining the amount of resources reserved per queue. This difficulty is in part the result of 
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5 how diffserv was designed. Diffserv was not defined with the intent of managing per 
application flow behavior. Rather, it was defined to manage aggregate flow behaviors in 
the core of the network. As the number of simultaneous applications increases in the CPN 
and access network, the use of diffserv without resource reservation breaks down. 
Leveraging a resource reservation approach can provide a mechanism for 
1 0 managing increasing numbers of applications. The reservation scheme need not 

necessarily require signaling. At subscription, time applications could reserve specific 
queues and could provide an intermediate solution. Longer term, as the number of 
applications continues to grow, a more dynamic reservation of resources will be required. 
In the dynamic case, applications may be able to reserve specific queues for the duration of 
15 the application flow, which will be released when they are done. In doing so, admission 
control to the DSL resources can be provided in a way that the applications behavior can 
be more clearly described. Use of Resource Reservation Protocol (RSVP) would provide 
an example of the former case. While having been defined for some time, actual RSVP 
implementations are elusive due to its general complexity and scaling limitations. 

- -20 -• Admission controLprovides one way to provide an application dedicated resources or to 

provide an indication when resources are not available. While conceptually attractive, it 
remains unclear if the complexity of such an approach is feasible. 
5. Reference Data Model 

In this section a description of the data required in each of the functional 
25 domains of the architecture (Regional/Access Network, RG, ASP, NSP, and 
subscriber) is presented. FIG. 8 illustrates a high level representation of the 
relationships between the different domains in accordance with some embodiments of 
the present invention. Based on this abstract view of the domains involved in 
providing an end-to-end service, a data model can be constructed. 
30 Dotted lines 1 and 2 illustrated in FIG. 8 indicate that information is 

exchanged between the modules not specifically discussed with respect to the 
interface reference model. The dashed lines illustrated in FIG. 8 indicate a physical 
connection and the solid lines illustrated in FIG. 8 indicate that information is 
exchanged within the scope of the interface reference model. In particular, lines 1 and 
35 2 illustrate exchanges between the subscriber and the NSP and ASP, respectively, 
when the subscriber, for example, signs up for service. Line 3 illustrates the 
configuration of the RG by the Regional/Access Network. It will be understood that 
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5 this may only be for the initial install. The ACS located with in the Regional/Access 
Network may handle all subsequent configuration changes. Line 4 illustrates the 
initiation of access sessions that are terminated in the DSL network. The ACS located 
with in the Regional/ Access Network may communicate with the RG for 
configuration updates. Finally, lines 5 and 6 of FIG- 8 illustrate communication 
10 between the NSP/ASP and the DSL network that establishes a DSL connection. The 
ASP and NSP may also communicate bandwidth and QoS changes per session or 
application. 

FIG. 9 depicts a UML model capturing the type of data used to support 
bandwidth and QoS management in accordance with some embodiments of the 

1 5 present invention. This model is provided for illustration purposes only and is not 

intended to represent a complete deployment implementation, which may use a wider 
scope of information beyond bandwidth and QoS. FIGS. 10 through 12 provide 
additional details within the main domains, in accordance with some embodiments of 
the present invention, and are described below. The remainder of this section 

20 provides a detailed-description of .the data records and attributes captured in the 
presented UML model. 

5.1 Subscriber Maintained Data 

The following data elements are maintained at Subscriber Premises (this 
record is maintained by the subscriber - it could be stored on a PC or any other 
25 storage device/media) in accordance with some embodiments of the present invention: 



Record 
Type 


Elements 


Description 


Source 


NSPSubscriber 
PPP Session 
Record 
970 




The subscribers need to know their 
DSLJineJD, NSPSubscriber JD and 
NSPSubscriber_Password for accessing their 
NSP networks. Only a single NSP PPP session 
record can exist. 






DSL_Line_ID 


DSL_Line_ID is a unique identifier for the DSL 
line. Currently the TN is used as such an 
identifier. 


DSL_Line_ID is provided 
by the Regional/Access 
Network Provider at 
subscription time. 




NSPSubscriber JD 


This ID is used for accessing the NSP networks. 


Assigned by the NSP at the 
time of subscription 




NSPSubscriber_ 
Password 


Subscriber_Password is initially set by the NSP, 
later it can be changed by the Subscriber. It is 
used together with the NSPSubscriber_lD to 
access the NSP networks. 


Initially assigned by the 
NSP at subscription time. 
Can be changed by the 
subscriber. 
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Personal 
NSPSubscriber 
PPP Session 
Record 
974 




The subscribers need to know their 
DSLJineJD, PersonalNSPSubscriberJD and 
Personal NSPSubscriber_Password for accessing 
their Personal NSP network. Multiple records 
can exist. 






DSL Line ID 


As defined above 


As defined above 




PersonalNSP 
Subscriber_ED 


This ID is used for accessing the Personal NSP 
networks. 


Assigned by the Personal 
NSP at the time of 
subscription. 




PersonalNSPSubscriber 
Password 


It is used together with the 
PersonalNSPSubscriber_ID to access the PNSP 
networks. 


Initially assigned by the 
PNSP at the time of 
subscription. Can be 
changed by the subscriber. 


ASPSubscriber 
PPP Session 
Record 

972 . 




The subscribers need to know their 
DSLJineJD, ASPSubscriber_ID and 
ASPSubscriber_Password for accessing their 
ASP services. For each application they 
subscribe to, they need to maintain their UserJD 
and Password. Only one ASP PPP session record 
can exist. 






DSL Line ID 


As defined above 


As defined above 




ASPSubscriberJD 


This ID is used for accessing the ASP networks. 


Provided by ASP at the 
time of subscription 




ASPSubscriber_ 
Password 


It is used together with the ASPSubscriberJD to 
access the ASP networks. 


Initially assigned by ASP 
at the time of subscription. 
Can be changed by the 
subscriber. 


User Account 

Record 

976, 978, 980 




This record is maintained by user/users of 
services provided over the Regional/Access 
Network. A user account is tied to a subscriber 
account. Multiple user accounts can be 
associated with a single subscriber account. 
Note: . 

There is one or multiple User Account Record 
under each of the NSPSubscriber PPP Session 
Record, Personal NSPSubscriber PPP Session 
Record, and ASPSubscriber PPP Session Record. 


Created at the time of 
subscription to ASP 
services 




UserJD 


This ID is used for accessing the given service. 


Assigned by a given ASP 
to a particular user at the 
time subscription 




UserPassword 


It is used together with the UserJD to access a 
given service, 


Initially assigned by a 
given ASP to a particular 
user at the time of 
subscription. Can be 
changed by the subscriber. 



5.2 Routing Gateway 
Routing Gateway is a customer premises functional element that provides IP routing and 
QoS capabilities. The main functions of the RG may include one or more of: IP routing 
between the CPN and the Access Network; multi-user, multi-destination support (Multiple 
simultaneous PPPoE sessions (started from the RG or from devices inside the CPN) in 
conjunction with non-PPP encapsulated IP (bridged) sessions); network Address Port 
Translation (NAPT); PPPoE pass though; multiple queues with scheduling mechanism; 
and/or IP QoS. 

The following data elements are maintained at the RG in accordance with 
some embodiments of the present invention: 
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Record 
Type 


Elements 


Description 


Source 


Routing 

Gateway Record 
902 




Routing Gateway Record is maintained by RG. 


It is initialized with the initial 
configuration by the manufacturer 
or configured by the user during the 
install process. The ACS can also 
update this record during and after 
the initial install. 




DSL Line ID 


As defined above ! 


As defined above 




DSL_Sync_Rate 


DSL_Sync_Rate is the current physical layer 
synch rate of the DSL line. This record 
includes both upstream and downstream 
metrics. It also includes what is the maximum 
obtainable synch rate 


It is populated by RG during modem 
training. 


NSP PPP 
Session Record 
904 




NSP PPP Session Record is maintained by the 
RG to store information specific to the 
community NSP access session. This session is 
launched by the RG and provides the CPN with 
a default route. Only one community NSP 
record can exist. 






NSPSubscriberJD 


This ID is used for accessing the DSL and NSP 
networks. 


Assigned by NSP at subscription 
time. 




NSPSubscriber_Pass 
word 


It is used together with the Subscriber_ID to 
access the DSL and NSP networks. 


NSPSubscriber_Password is initially 
set by the NSP, later it can be 
changed by the Subscriber. 




Session_Classifier 


This parameter contains classification 
parameters to identify the NSP PPP session 
(i.e. Ethertype and FQDN). 


This value is populated based on 
configuration data received from the 
ACS. 




Session_Priority 


Optional - Indicates the priority level of the 
NSP PPP connection relative to the other PPP 
sessions present - only required if DSL 
bandwidth is shared across PPP sessions and"*.--- 
need to establish a priority relationship across 
the PPP sessions ' r "~ '" 


This value is populated based on 
configuration data received from the 
ACS. 




Session_Bandwidth 


The Session_Bandwidth contains information 
about the maximum bandwidth assigned to this 
NSP PPP access session. 


This value is initialized based on a 
default value or on the Profile Data 
received from the ACS. 


ASP PPP 
Session Record 
906 




ASP PPP Session Record is maintained by the 
RG to store information specific to the ASP 
access session. This PPP session is launched 
by the RG and receives routes, via RIP, to the 
ASP network. Onlv one ASP record can exist. 






ASPSubscriber_ID 


This ID is used for accessing the ASP network 
(and potentially ASP applications although the 
RG would not be involved). 


Assigned by ASP at subscription 
time 




ASPSubscriber_Pass 
word 


It is used together with the ASPSubscriber_ID 
to access the Regional/Access Network, (and 
potentially ASP applications although the RG 
would not be involved) 


Initially set by the ASP, later it can 
be changed by the Subscriber 




Session_Classifier 


This parameter contains classification 
parameters to identify the ASP PPP session 
(i.e. Ethertype and FQDN). 


This value is populated based on 
configuration data received from the 
ACS. 




Session_Priority 


Optional - Indicates the priority level of the 
ASP PPP connection relative to the other PPP 
sessions present - only required if DSL 
bandwidth is shared across PPP sessions and 
need to establish apriority relationship across 
the PPP sessions 


This value is populated based on 
configuration data received from the 
ACS. 




Session_Bandwidth 


The Session_Bandwidth contains information 
.about the maximum bandwidth (upstream and 
downstream) assigned to this ASP PPP access 
session. 


This value is populated based on 
configuration data received from the 
ACS. 


Application 
Flow Record 

Q1 A 




The Application Flow Record is maintained 
by the RG for each application service that 

to. It is used to store application specific data. 
Multiple application records can exist. 






Flow_Classifier 


Flow_Classifier contains classification 
parameters to identify the application flow (IP 
5 tuple). 


This value is populated based on 
configuration data received from the 
ACS. 




FlowPriority 


Indicates the priority level of the application 


This value is populated based on 
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within the ASP PPP connection. This 
parameter indicates the treatment of the 
application flow (what queue it should be 
placed in) as well as any marking requirements 
(DSCP). 


configuration data received from the 
ACS. 




Flow_Bandwidth 


Flow_Bandwidth parameter is assigned to the 
given application based on the negotiated value 
between the ASP and the Regional/Access 
Network. It indicates the maximum upstream 
and downstream bandwidth. It is used by the 
RG to shape and police the application flow. 


This value is populated based on 
configuration data received from the 
ACS. 

- 


Personal NSP 
PPP Session 
Record 
908 




Personal NSP PPP Session Record is 
maintained by the RG to store information 
specific to the Personal NSP access session. 
Multiple records can exist. 






Session_Classifier 


This parameter contains classification 
parameters to identify the PNSP PPP session 
(i.e. Ethertype and FQDN). 


This value is populated based on 
configuration data received from the 
ACS. 




Session_Priority 


Optional - Indicates the priority level of the 
PNSP PPP connection relative to the other PPP 
sessions present - only required if DSL 
bandwidth is shared across PPP sessions and 
need to establish a priority relationship across 
the PPP sessions. 


This value is populated based on 
configuration data received from the 
ACS. 




Session_Bandwidth 


The Session_Bandwidth contains information 
about the maximum bandwidth assigned to the 
PNSP access service. 


This value is populated based on 
configuration data received from the 
ACS. 



5 

5.3 Regional/Access Network 



The primary function of the Regional/Access Network is to provide end-tb- 
end data transport between the customer premises and the NSP or ASP. The 
Regional/Access Network may also provide higher layer functions, such as QoS and 
1 0 bandwidth management. QoS may be provided by tightly coupling traffic-' 

engineering capabilities of the Regional Network with the capabilities of the BRAS. 

The following data elements are maintained' at the Regional/Access Network 
in, for example, a Regional/Access Network Record 920 in accordance with some 



embodiments of the present invention: 



Record Type 


Elements 


Description 


Source 


DSL Line Record 
922 




The DSL line record is maintained in the 
Regional/Access Network and is unique to 
each DSL line. It maintains data specific to 
a DSL line and the sessions that traverse it. 






DSL Line ID 


As defined above 


As defined above 




DSL_Sync_Rate 


DSL_Sync_Rate is the current physical 
layer synch rate of the DSL line. This 
record includes both upstream and 
downstream metrics. It also includes what 
are the maximum obtainable data rates in 
either direction. 


This data is obtained from the 
DSLAM EMS and the RG 


NSP PPP Session 

Record 

926 




NSP PPP Session Record is maintained by 
the Regional/ Access Network to store 
information specific to the community NSP 
PPP access sessions. The NSP access 
record is tied to the DSL Line Record. 
Only.one can exist. 






SP_ID 


Uniquely identifies the NSP that the 
subscriber has a relationship with. Used to 
cross reference users to NSPs who make 
turbo/QoS requests. 


Assigned by the 
Regional/Access Network 
Provider when a wholesale 
relationship is established with 
the NSP 




Session Classifier 


This parameter contains classification 


Provided by the NSP at 
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parameters to identify the NSP PPP session 
(i.e. Ethertype and FQDN). 


subscription time. 




Session_Priority 


Optional - Indicates the priority level of the 
NSP PPP connection relative to the other 
PPP sessions present - only required if 
DSL bandwidth is shared across PPP 
sessions and need to establish a priority 
relationship across the PPP sessions 


The Regional/ Access Network 
Provider initializes this value at 
subscription time based on the 
business model and type of 
wholesale access that is being 
sold to the NSP and its 
relationship to the ASP or the 
PNSP sessions. 




Session_Bandwidth 


The Session_B and width contains 
information about the maximum bandwidth 
(upstream and downstream) assigned to this 
NSP PPP session. 


This value is set by the NSP. 


PersonalNSP PPP 
Session Record 
930 




PersonalNSP PPP Session Record is 
maintained by the Regional/Access 
Network to store information specific to the 
Personal NSP PPP access sessions. 
Multiple records can exist. 






SP ID 


As defined above 


As defined above 




Session_Classifier • 


This parameter contains classification 
parameters to identify the PNSP PPP 
session (i.e. Ethertype and FQDN). 


Provided by the NSP at 
subscription time. 




Session_Priority 


Optional - Indicates the priority level of the 
PNSP PPP connection relative to the other 
PPP sessions present - only required if 
DSL bandwidth is shared across PPP 
sessions and need to establish a priority 
relationship across the PPP sessions 


The Regional/Access Network 
Provider initializes this value at 
subscription time based on the 
business model and type of 
wholesale access that is being 
sold to the NSP and its 
relationship to the ASP or the 
PNSP sessions. Assigned by 
PNSP and passed to : '- -.' - 
Regional/Access network via 
NNI message interface. ~ 




Session_Bandwidth 


The Session_Bandwidth contains 
information about the maximum bandwidth 
(upstream and downstream) assigned to this 
PNSP PPP session. 


This value is initially set by the 
PNSP, 


ASP PPP Session 

Record 

928 




ASP PPP Session Record is maintained by 
the Regional/Access Network to store 
information specific to the ASP PPP 
session. The ASP PPP Record is tied to the 
DSL Line Record. Only one ASP record 
can exist. 


- 




SPJD 


As defined above 


As defined above 




Session_Classifier 


This parameter contains classification 
parameters to identify the ASP PPP session 
(i.e. Ethertype and FQDN). 


Provided by the ASP at 
subscription time 




Session_Priority 


Optional - Indicates the priority level of the 
ASP PPP connection relative to the other 
PPP sessions present - only required if 
DSL bandwidth is shared across PPP 
sessions and need to establish a priority 
relationship across the PPP sessions 


The Regional/Access Network 
Provider initializes this value at 
subscription time based on the _ 
business model and type of 
wholesale access that is being . 
sold to the NSP and its 
relationship to the ASP or the 
PNSP sessions. Assigned by 
ASP and passed to 
Regional/Access network via 
NNI message interface. 




Session_Bandwidth 


The Session_Bandwidth contains 
information about the maximum bandwidth 
(upstream and downstream) assigned to this 
ASP PPP session. 


This value is initially set by the 
Regional/Access Network 
* Provider, but could be modified 
by individual ASPs that request 
more bandwidth for their 
application. An alternative 
model is that this value is set to 
the max value initially and ASPs 
only affect their allotment of 
bandwidth within the PPP 
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session. 


Application Flow 

Record 

932 




The Application Flow Record contains 
specific details about an application within 
the ASP session. This record is tied to the 
ASP account record. Many application 
records can be associated with an ASP 
account record. 






Flow_CIassifier 


Flow_Classifier contains classification 
parameters to identify the application flow 
(IP 5 tuple). It is used by the BRAS & the 
RG. 


Values provided by the ASP. 




Flow_Priority 


Indicates the priority level of the 
application within the ASP PPP connection. 
This parameter indicates the treatment of 
the application flow (what queue it should 
be placed in) as well as any marking 
requirements (DSCP). It is used by the 
BRAS and the RG 


Provided by the ASP. 
Regional/Access Network 
Provider provides available 
options to select. 




Flow_Bahdwidth 

- 


Flow_B and width parameter is assigned to 
the given application based on the 
negotiated value between the ASP and the 
Regional/ Access Network. It indicates the 
maximum upstream and downstream 
bandwidth. It is used by the BRAS & the 
RG to shape and police the application 
flow. 


These values are provided by 
the ASP to meet the needs of the 
application. 


Service Provider 

Record 

924 




The service Provider Record is used to 
authenticate service providers (NSPs, 
ASPs) who wish to query the 
Regional/Access Network for information 

and make bandwidth and or QoS requests. 






SP ID 


As defined above 


As defined above 


- • 


SP_Credentials 


Used to authenticate this service provider 
together with SP_ID when connecting to 
the Regional/Access Network. 


Assigned by the 
Regional/Access Network 
Provider 




Authorization 


Represents what records the SP has access 
to (DSL line records can it make 

queries/modifications to) 


Assigned by the 
Regional/Access Network 
Provider 




CDR_Data 


Stores billing data for wholesale access to 
Turbo and QoS controls 


This data is generated by the 
Regional/ Access Network 
Provider 



5,4 Application Service Provider 

The Application Service Provider (ASP) is defined as a Service Provider that 
shares a common infrastructure provided by the Regional/Access Network and an JP 
address assigned and managed by the Regional Network Provider. In particular 
embodiments of the present invention, the ASP provides one or more of: application 
services to the subscriber (gaming, video, content on demand, IP Telephony, etc.); 
service assurance relating to this application service; additional software or CPE; 
and/or a contact point for all subscriber problems related to the provision of specific 
service applications and any related subscriber software. However, the ASP may not 
provide or manage the assignment of IP address to the subscribers. 

The following data elements may be maintained at the ASP in accordance with 
some embodiments of the present invention: 
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5 



Record 
Type 


Elements 


Description 


Source 


ASP Record 
960 




ASP Record is maintained by each service provider. 
This record contains the service provider's name, 
password, and other related information that 
identifies this unique ASP and is used to 
communicate with Regional/Access Network 
Provider. 






ASPJD 

- 


Used to uniquely identify an ASP that has a business 
relationship with Regional/Access Network 
Provider. 


Assigned by 

Regional/Access Network 
Provider at the time of 
connecting the ASP to the 
ASP network. 




ASP_Credentials 


Used to authenticate an ASP together with ASP_ID 
when a service session is established with a 
Regional/Access Network Provider. 


Assigned by 

Regional/ Access Network 
Provider at the time of 
connecting the ASP to the 
ASP network. 


ASP Subscriber 

Record 

962 




ASP Subscriber Record is maintained by ASP that 
provides the application service. This record 
uniquely identifies the subscriber and service related 
data. 






DSL Line ID 


As defined above 


As defined above 




ASPSubscriberJD 


This ID is used for accessing the DSL and ASP 
networks. 


Assigned by the ASP at the 
time of subscription. 




ASPSubscriber_ 
Password 


It is used together with the ASPSubscriber_ID to 
access the ASP application. 
Note: The ASP Subscriber ID and Password are 
only used by ASP for its own purpose and will not 
be used or referenced by Regional/Access Network 
for authentication purpose. It is just for maintaining 
ASP data integrity. 


Assigned by the ASP at the 
time of subscription. 




Session_Classifier 


Local copy of Regional/Access Network ASP PPP 
Session Classification info. 


Acquired from the 
Regional/Access Network 
through the ANI interface. 




Session_Priority 


Local copy of Regional/Access Network ASP PPP 
Session Priority info. 


Acquired from the 
Regional/Access Network 
through the ANI interface. 




Session_Bandwidth 


Local copy of the Regional/ Access Network ASP 
PPP Session Bandwidth Info. 


Acquired from the 
Regional/Access Network 
through the ANI interface. 


Application Flow 
Control Record 
966 




This record is maintained by the ASP and used to 
store application specific information such as 
bandwidth arrangement and QoS settings. This 
record is tied to the ASP bandwidth Record. 
Multiple Application Record can be associated with 
one single ASP bandwidth record. 






Flow_Classifier 


Flow_Classifier contains classification parameters 
to identify the application flow (IP 5 tuple). It is 
used by the BRAS & the RG. 


Values provided by the ASP. 




Flow_Priority 


Indicates the priority level of the application within 
the ASP PPP connection. This parameter indicates 
the treatment of the application flow (what queue it 
should be placed in) as well as any marking - 
requirements (DSCP). It is used by the BRAS and 
the RG 


Provided by the ASP. The 
Regional/Access Network 
Provider specifies available 
options to select. 




FlowBandwidth 


Flow_Bandwidth parameter is assigned to the given 
application based on the negotiated value between 
the ASP and the Regional/Access Network Provider. 
It indicates the maximum upstream and downstream 
bandwidth. It is used by the BRAS & the RG to 
shape and police the application flow. 


These values are provided 
by the ASP to meet the 
needs of the application. 


ASP User Account 
964 




This record is maintained by the ASP. An ASP user 
account is tied to an ASP subscriber account. 
Multiple user accounts can be associated with a 
single subscriber account. 






UserJD 


This ID is used for accessing the given service. 


Assigned by a given ASP to 
a particular user. 




User_Password 


It is used together with the User_ID to access a 
given service. 


User Password is initially 
assigned by an ASP. Can be 
changed by the user. 
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5 

5.5 Network Service Provider 

The Network Service Provider (NSP) is defined as a Service Provider that 
requires extending a Service Provider-specific Internet Protocol (IP) address. This is 
the typical application of conventional DSL service. The NSP owns and procures 

10 addresses that they, in turn, allocate individually or in blocks to their subscribers. The 
subscribers are typically located in Customer Premises Networks (CPNs). The NSP 
service may be subscriber-specific, or communal when an address is shared using 
NAPT throughout a CPN. The NSP may include Internet Service Providers (ISPs) 
and Corporate Service Providers (CSPs); may be responsible for overall service 

15 assurance; may provide CPE, or software to run on customer-owned CPE, to support 
a given service; may provide the customer contact point for any and all customer 
related problems related to the provision of this service; and/or may authenticate 
access and provides and manages the assignment of IP address to the subscribers. 
... The following data elements are maintained at the NSP in accordance with 

20- some embodiments of the present invention: 



Record 
Type 


Elements 


Description 


Source 


NSP Record 
940, 950 




NSP Record is maintained by each NSP. This 
record contains the service provider's name, 
password,. and other related information that 
identifies this unique service provider and is 
used communicate with access NSP. 






NSPJD 


Uniquely identifies the NSP that the subscriber 
has a relationship with. Used to cross 
reference users to NSPs who make turbo/QoS 
requests 


Assigned by Regional/Access 
Network Provider at the time 
of connecting the NSP. 




NSP_Credentials 


Used to authenticate this NSP together with 
NSP_ID when a service session is established 
with a DSL access network for requesting a 
network service. 


Assigned by Regional/Access 
Network Provider at the time 
of connecting the NSP. 


NSP Subscriber 
Record 
942, 952 




NSP Subscriber Record is maintained by NSP 
that provides the network service. This record 
uniquely identifies the subscriber and service 
related data. ^ 






DSL Line ID 


As defined above 


As defined above 




NSPSubscriberJD 


This ID is used for accessing the DSL and 
NSP networks. 


Assigned to a DSL subscriber 
by the NSP. 




NSPSubscriber_ 
Password 


It is used together with the NSPSubscriberJD 
to access the NSP application. 
Note: The NSP Subscriber ID and Password 
are only used by NSP for its own purpose and 
will not be used or referenced by 
Regional/ Access Network for authentication 
purpose. It is just for maintaining the NSP data 
integrity. 


Assigned by the ASP at the 
time of subscription. 




Session_Classifier 


Local copy of Regional/Access Network NSP 
PPP Session Classification info 


Acquired from the 
Regional/Access Network 
through the NNI interface. 




Session_Priority 


Local copy of Regional/Access Network NSP 
PPP Session Priority info. 


Acquired from the 
Regional/Access Network 
through the NNI interface. 




Sess ion_Bandwidth 


Local copy of the Regional/Access Network 
ASP PPP Session Bandwidth Info. 


Acquired from the 
Regional/Access Network 
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through the NNI interface. 


NSP User Account 
944, 954 




This record is maintained by the NSP. A NSP 
user account is tied to an NSP subscriber 

»nt AAll1tlv\1o near ft^/^AI lY^tT POfl 

account, lviuiiipie user diA-ounub can dc 
associated with a single subscriber account. 






UserJD 


This ID is used for accessing the given service. 


Assigned by a given NSP to a 
particular user. 




User_Password 




User_Password is initially 
assigned by a NSP. Can be 
changed by the user. 



5 

6. Reference Interface Specification and Detailed Message Flow 

This interface reference specification defines an interface between the 
Regional/ Access Network and a Network Service Provider (NSP), a Personal NSP 
(PNSP), and an Application Service Provider (ASP) as well as an interface between 
10 the Regional/Access Network and Routing Gateway (RG) for enabling the 

NSP/PNSP/ASP to utilize the bandwidth and QoS management capabilities provided 
by the Regional/Access Network in their NSP/PNSP/ASP applications, in accordance 
with some embodiments of the present invention. 

6.1 Interface Between RG and Regional/Access Network 
15 This section defines the messaging interface between the Regional/ Access 

Network and the Routing Gateway, in accordance with some embodiments of the 
, present invention. This interface does not define any message for RG or ACS 
authentication assuming both of them are part of the DSL Network infrastructure. 

20 1. UpdateSessionBandwidthInfo(DSLJL,ine_ID, SP_ID, Session_Classifier, 
SessionJPriority, SessionJBandwidth) 

This message is sent from the Regional/ Access Network to a specified RG (via 
ACS) as a notification when new bandwidth and QoS information for a PPP session 
becomes available. The bandwidth and QoS related parameters include 

25 Session_Classifier, Session_Priority, and Session_Bandwidth. These parameters will 
be stored in the NSP PPP Session Record, PNSP PPP Session Record, or ASP PPP 
Session Record depending on the SP_ID. These session records are defined in the 
DSL Data Reference Model. 
DSL_Line_ID: Subscriber's line identification. 

30 SPJDD: The identifier of service provider requesting for service. The service provider 
can only be NSP, PNSP, or ASP. 
SessionClassifier: PPP session classifier. 
SessionJPriority: Session priority indicator. 
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5 SessionJBandwidth: Bandwidth data including upstream bandwidth and downstream 
bandwidth. 

2. UpdateSessionBandwidthAck(DSL_Line JGD, SP_ID) 

This message is sent from the RG to the Regional/Access Network (via ACS) 
10 as an acknowledgement of receiving the update session bandwidth information 
notification. 

DSL_Line_ID: Subscriber's line identification. 

SP_ID: The identifier of service provider requesting for service. The service provider 
can only be NSP 5 PNSP, or ASP. 

15 

3. UpdateAppFlowControIInfo(DSL_Line_ID, SPJD, Flow_Classifier, 
FlowJPriority, FlowJBandwidth) 

This message is sent from the Regional/ Access Network to a specified RG (via 
* ACS) as a notification of new bandwidth and QoS info for application flow becoming 
20 available. The parameters including Flow_Classifier, Flow_Priority, and 

Flow_Bandwidth will replace the existing data stored in the Application Flow Control 
Record defined in the Regional/ Access Data Reference Model. 
DSL_Line_ID: Subscriber's line identification. 

SP__ID: The identifier of service provider requesting for service. The service provider 
25 can only be NSP 5 PNSP, or ASP. 

Flow_Classifier: Application flow classifier. 
FlowJPriority: Priority queue indicator. 

Flow_Bandwidth: Flow bandwidth information for shaping and policing. 

30 4. UpdateAppFlowControlAck(DSLJLine_ID, SP _ID) 

This message is sent from the RG to the Regional/ Access Network (via ACS) 
as an acknowledgement of receiving the update application flow control info 
notification. 

DSLJLine_ID: Subscriber's line identification. 
35 SP_ID: The identifier of service provider requesting for service. The service provider 
can only be NSP 5 PNSP, or ASP. 
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5 5. UpdateSessionBandwidthRequest(DSL JJneJTO, SPJTO) 

This message is sent from the RG to the Regional/ Access Network (via ACS) 
as a request for obtaining the PPP session level of the bandwidth and QoS settings 
stored at the Regional/Access Network for the specified subscriber line. 
DSL_Line_ID: Subscriber's line identification. 
10 SP_ID: The identifier of service provider requesting for service. The service provider 
can only be NSP, PNSP, or ASP. 

6. UpdateSessionBandwidthResponse(DSLJLineJTO, SP_ID, Session_Classifier, 
Session_Priority, SessionBandwidth, ReturnCode) 

1 5 This message is sent from the Regional/ Access Network to the RG (via ACS) 

as a response for getting the PPP session level of the bandwidth and QoS settings 
request. 

DSL_Line_ID: Subscriber's line identification. 

SP_ID: The identifier of service provider requesting for service. The service provider 
20 can only be NSP, PNSP,. or ASP. 

Session_Classifier: PPP session classifier. 
Session JPriority: Session priority indicator. 

Session_Bandwidth: Session bandwidth information including upstream bandwidth 
and downstream bandwidth. 
25 Return_Code: Return code from the Regional/Access Network, indicating if the 
request is accomplished successfully. 

7. UpdateAppFlowControlRequest(DSL_Line _ID, SP_ID) 

This message is sent from the RG to the Regional/Access Network (via ACS) 
30 as a request for obtaining the application flow level of the bandwidth and QoS settings 
stored at the Regional/Access Network for the specified subscriber line. 
.DSL_Line_ID: Subscriber's line identification. 

SP_ID: The identifier of service provider requesting for service. The service provider 
can only be NSP, PNSP, or ASP. 

35 

8. UpdateAppFlowControlResponsepSLJLine_ID, SPJD, Flow_Classifier, 
Flow Priority, Flow_Bandwidth, Return_Code) 
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5 This message is sent from the Regional/ Access Network to the RG (via ACS) 

as a response for getting the application flow level of the bandwidth and QoS settings 
request. 

DSL_Line_ID: Subscriber's line identification. 

SP _ID: The identifier of service provider requesting for service. The service provider 
1 0 can only be NSP, PNSP, or ASP. 

Flow_Classifier: Application flow classifier. 
FlowJPriority: Priority queue indicator. 

FlowJBandwidth: Flow bandwidth information for shaping and policing. 
- Return_Code: Return code from the DSL Network, indicating if the request is 
1 5 accomplished successfully. 

6.2 Interface Between Regional/ Access Network and ASP 
This section defines the messaging interface between the Regional/ Access 
Network and the Application Service Providers, in accordance with some 
embodiments of the present invention. : 
20 • * "i . - 

1. EstablishServiceSessionRequest (SP_ID, SP_Credentials) 

This message is sent from an ASP to the Regional/Access Network as a 
request for establishing a communication session. All the ASPs need to be 
authenticated by the Regional/ Access-Network before the network bandwidth and 
25 QoS service capabilities can be accessed. With this request, the ASP can specify a life 
span of this session by providing a life span parameter that could be imbedded in the 
SP_Credentials. When the specified life span expires, the ASP must resend this 
request to establish a new service session. 

SP_ID: Service Provider Identification. SP_CredentiaIs: Service Provider 
30 Credentials. 

2. EstablishServiceSessionResponse (Authorization, Return_Code) 

This message is sent from the Regional/Access Network to the service 
provider as a response for the communication session establishment request. The 
35 Regional/Access Network returns an authorization code indicating what services and 
resources are authorized for the service provider to access. 
Authorization: Authorization code indicating what Regional/ Access Network 
resources is authorized for the service provider to access. 
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5 Return_Code: Return code from the Regional/Access Network, indicating if the 
request is accomplished successfully. 

3, CreateAppFlowControlRecordRequest (Authorization, DSL_Line_ID, SP_ID, 
Flow_Classifier, Flow JPriority, Flow_Bandwidth) 

1 0 This message is sent from an ASP to the Regional/ Access Network as a 

request for creating an application specific flow control record defined as Application 
Flow Control Record in DSL Data Model. The initial settings are provided with 
Flow_Clasifier, SP _ID, Flow_Priority, and Flow_Bandwidth. 

Authorization: Authorization code obtained when the service session is established. 
15 DSL_Line_ID: Subscriber's line identification. 

SP_ID: The identifier of service provider requesting for service. The service provider 
can only be ASP. 

Flow_Classifier: 5 -tuple (source IP address, source port, destination IP address, 
destination port, protocol type) identifying a unique application flow. 
20 Flow_Priority: Priority queue setting , 

Flow_Bandwidth: Flow bandwidth information for shaping and policing. 

4. CreateAppFlowControlRecordResponse (DSL_Line_ID, Return_Code) 

This message is sent from the Regional/Access Network to the ASP as a 
25 response for the creation of the application flow control record request. 
DSL_Line_ID: Subscriber's line identification. 

Return_Code: Return code from the Regional/Access Network, indicating if the 
request is accomplished successfully. 

30 5. DeleteAppFlowControlRecordRequest (Authorization, DSL_Line_ID, SP_ID, 
Flow_Classifier) 

This message is sent from an ASP to the Regional/Access Network as a 
request for deleting an Application Flow Control Record defined in DSL Data Model. 
Authorization: Authorization code obtained when the service session is established. 
35 DSLJLineJD: Subscriber's line identification. 

SP_ID: The identifier of service provider requesting for service. The service provider 
can only be ASP. 

Flow_Classifier: Identifier of an application flow. 
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6. DeleteAppFlowControlRecordResponse (DSL_LineJD, Return_Code) 

This message is sent from the Regional/ Access Network to the ASP as a 
response for the deletion of the application flow control record request. 
DSL_Line_ID: Subscriber's line identification. 
1 0 Return_Code: Return code from the Regional/Access Network, indicating if the 
request is accomplished successfully. 

7. ChangeAppFlowControlRequest (Authorization, DSLJLine JD, SP_ID, 
Flow_Classifier, FlowJPriority, FlowJBandwidth) 

15 An ASP can send this message to the Regional/Access Network as a request 

for changing the Priority and Shaping Data defined in the Application Flow Control 
Record of the DSL Data Model. 

Authorization: Authorization code obtained when the service session is established. 
DSL_Line_ID: Subscriber's line identification. 
20 SP_ID: The identifier of service provider requesting, for-service. The service provider 
should be an ASP. 

Flow_Classifer: Application traffic flow identifier. . - • - * r - • 

Flow_Priority: The application priority queue indicator for replacing the existing - 
settings. - ^ 

25 FlowJBandwidth: Flow bandwidth information for replacing the existing settings. 

8. ChangeAppFlowControlResponse (DSL_Line_ID, Return_Code) 

This message is sent from the Regional/Access Network to the service 
provider as a response for the bandwidth change request. A Return_Code is sent back 
30 indicating whether the change is successful. 

DSLLinelD: Subscriber's line identification. 

Return_Code: Return code from the Regional/Access Network, indicating if the 
request is accomplished successfully. 

35 9. QueryAppFlowControlRequest (Authorization, DSLJLine_ID, SP_ID, 
Flow_Classifier) 
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5 An ASP can send this message to the Regional/ Access Network as a request 

for querying the application specific priority and shaping information contained in the 
Application Flow Control Record. 

Authorization: Authorization code obtained when the service session is established. 
DSL_Line_ID: Subscriber's line ID. 
10 SP_ID: Identifier of the service provider requesting for bandwidth and priority 
information. 

Flow_Classifier: Identifier of an application flow. 

10. QueryAppFlowControlResponse (DSL_Line_ID, Flow_CIassifier, 
1 5 Flow JPriority, Flow_Bandwidth, Return_Code) 

This message is sent from the Regional/Access Network to the service 
provider as a response for the bandwidth info request. The bandwidth data record is 
returned. 

DSL_Line_ID: Subscriber's line identification. 

20 Flow_Classifier: Identifier of an application flow. , 

Flow_Priority: Current priority queue setting. 

Flow_Bandwidth: Current bandwidth setting for shaping and policing. 
Return_Code: Return code from the Regional/ Access Network, indicating if the 
request is accomplished successfully. 

25 

11. QuerySessionBandwidthRequest (Authorization, DSL_LineJD, SP_ID) 

An ASP, can send this message to the Regional/Access Network as a request 
for querying the PPP session bandwidth' and priority information associated with the 
specified DSL_Line _ID. The data is stored in ASP PPP Session record defined in the 
30 DSL Data Model. 

Authorization: Authorization code obtained when the service session is established. 
DSL_Line_ID: Subscriber's line ID. 

SP JD: Identifier of the service provider requesting for bandwidth and priority 
information. 

35 12. QuerySessionBandwidthResponse (DSL_Line_ID, Session_Classifier, 
Session_Priority, SessionBandwidth) 
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5 This message is sent from the Regional/Access Network to the service 

provider as a response for the bandwidth info request. The bandwidth data record is 
returned. 

DSLJLine ID: Subscriber's line identification. 

Session_Classifier: PPP session classifier used to identify PPP session traffic flow. 
10 Session JPriority: Current Priority queue setting. *■ 

Session_Bandwidth: Current session bandwidth setting. 

13. TerminateServiceSessionRequest (SP _ID, Authorization) 

This message is sent from an ASP to the Regional/Access Network as a 
1 5 request for terminating a communication session. 
SPID: Service Provider Identification. 

Authorization: Authorization code indicating what Regional/Access Network 
resources is authorized for the service provider to access. 

20 14. TerminateServiceSessionResponse (SP_ID, Return_Code) 

This message is sent from the Regional/ Access Network to the service provider as a 
response for the communication session termination request. 
SP_ID: Service Provider Identification. 

Return_Code: Return code from the Regional/Access Network, indicating if the 
25 request is accomplished successfully. 

6.3 Interface Between Regional/Access Network and NSP 

This section defines the messaging interface between the Regional/Access 
Network and Network Service Provider, in accordance with some embodiments of the 

30 present invention. 

1. EstablishServiceSessionRequest (SP_ID, SP_Credentials) 

This message is sent from a NSP to the Regional/Access Network as a request 
for establishing a communication session. The NSPs need to be authenticated by the 
Regional/Access Network before the network bandwidth and QoS service capabilities 

35 can be accessed. With this request, the NSP can specify a life cycle of this session by 
providing a life span parameter imbedded in the SP_Credentials. When the specified 
life span expires, the NSP must resend this request to establish a new service session. 
SP ID: Service Provider Identification. 
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5 SP_Credentials: Service Provider Credentials. 

2. EstablishServiceSessionResponse (Authorization, Return_Code) 

This message is sent from the Regional/Access Network to the service 
provider as a response for the communication session establishment request. The 
10 Regional/Access Network returns an authorization code indicating what services and 
resources are authorized for the service provider to access. 
Authorization: Authorization code indicating what Regional/Access Network 
resources is authorized for the service provider to access. 

ReturnCode: Return code from the Regional/ Access Network, indicating if the 
1 5 request is accomplished successfully. 

3. ChangeSessionBandwidthRequest (Authorization, DSLJLine_ID, SP_ID, 
Session_Classifier, Session_Priority, SessionJBandwidth) 

A NSP can send this message to the Regional/Access Network as a request for 
20 changing the PPP session bandwidth and priority information associated with the 

specified DSL_Line_JD. The data is stored in the NSP PPP Session Record defined 
in the DSL Data Model. 

Authorization: Authorization code obtained when the service session is established. 
DSL_Line_ID: Subscriber's line identification. 
25 SP_ID: Identifier of service provider requesting for service. 

Session_Classifier: PPP session classifier used to identify PPP session traffic flow. 
SessionPriority: Session priority indicator setting to replace the current one. 
SessionJBandwidth: Session bandwidth information for replacing the existing one. 

30 4. ChangeSessionBandwidthResponse (DSL_Line_ID, Return_Code) 

This message is sent from the Regional/ Access Network to the service 
provider as a response for the bandwidth change request. A Return_Code is sent back 
indicating whether the change is successful. 
DSLJLine_ID: Subscriber's line identification. 
35 Return_Code: Return code from the Regional/Access Network, indicating if the 
request is accomplished successfully. 

5. QuerySessionBandwidthRequest (Authorization, DSLJLineJD, SPJD) 
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5 A NSP can send this message to the Regional/ Access Network as a request for 

querying the PPP session bandwidth and priority information associated with the 
specified DSL_Line_ID. The data is stored in the NSP PPP Session Record defined 
in the DSL Data Model. 

Authorization: Authorization code obtained when the service session is established. 
10 DSL_Line__ID: Subscriber's line ID. 

SP_ID: Identifier of the service provider requesting for bandwidth and priority 
information. 

6. QuerySessionBandwidthResponse (DSL_Line_ID, Session_Classifier, 
15 SessionJPriority, Session_Bandwidth) 

This message is sent from the Regional/ Access Network to the service 
provider as a response for the bandwidth info request. The bandwidth data record is 
returned. 

DSL_Line_ID:, Subscriber's line identification. 
20. SessionXlassifier: PPP session classifier used to identify PPP session traffic flow. 
Session_Priority: Current Priority queue setting. 
SessionJBandwidth: Current session bandwidth setting. 

7. TerminateServiceSessionRequest (SP_ID, Authorization) 

25 This message is sent from an NSP to the Regional/ Access Network as a 

request for terminating a communication session. 
SP_ID: Service Provider Identification. 

Authorization: Authorization code indicating what Regional/Access Network 
resources is authorized for the service provider to access. 
30 8. TerminateServiceSessionResponse (SP_ID, Return_Code) 

This message is sent from the Regional/ Access Network to the service 
provider as a response for the communication session termination request. 
SP_ID: Service Provider Identification. 

Return_Code: Return code from the Regional/ Access Network, indicating if the 
35 request is accomplished successfully. 

6.4 Application Framework Infrastructure 
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5 An Application Framework Infrastructure, in accordance with some embodiments 

of the present invention, is illustrated in FIG. 13 and is a reference implementation model 
for enabling the ASP, NSP, and/or Personal NSP to utilize the bandwidth and QoS , 
management capabilities. This framework infrastructure is supported by seven functional 
elements, including AM Protocol Handler, NNI Protocol Handler, UNI Protocol Handler, 

1 0 DSL Service Manager, DSL Session Data Store, Provision Interface, and BRAS Adapter, 
in accordance with some embodiments of the^present invention. For realizing the DSL 
network bandwidth and QoS management capabilities, this infrastructure may interact 
with the Routing Gateway via an Automated Configuration Server (ACS) and the BRAS 
to set appropriate policies upon receiving a request from the ASP, NSP, or PNSP, as 

15 depicted in FIG. 13. 

The communication interface between the Regional/Access Network and an ASP 
is defined as the Application-to-Network Interface (AM). The communication interface 
between the Regional/Access Network and a NSP or PNSP is defined as the Network-to- 
Network Interface (NNI) as discussed above with respect to the Regional/Access Interface. 

20 Through this framework infrastructure, the ASP, NSP, and/or PNSP can use the DSL 

Network bandwidth and QoS management capabilities to create their bandwidth and QoS 
"aware" applications. To enable the communication and service creation, a DSL Service 
API may be defined as a part of the Regional/Access Application Framework 
Infrastructure. This API may be a reference procedural implementation of the ANI and 

25 NNI. 

' Any suitable communication interface between the application framework and 
the BRAS and ACS may be utilized and, therefore, will not be discussed in detail 
herein. An interface may be used at these points and may be defined as part of the 
network element requirements. The use of Common Open Policy Service (COPS) is 
30 an example standard interface that may be implemented at these points to push 
changes into the ACS and BRAS. 

6.4.1 Framework Infrastructure Element Functional Description 
This section describes the main functions of each element of the Application 
Framework Infrastructure as illustrated in FIG. 13, in accordance with some 
35 embodiments of the present invention. 
ANI Protocol Handler 

The ANI Protocol Handler takes a request message from the ASP application, 
passes the request to the DSL Service Manager, waits for the response from the DSL 
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5 Service Manager, and sends the response message back to the ASP that requests the 
service. The protocol used in this prototype is the Application-to-Network Interface 
defined in this proposal. 
NNI Protocol Handler 

The NNI Protocol Handler takes a request message from the NSP/PNSP 
10 application, passes the request to the DSL Service Manager, waits for the response 
from the DSL Service Manager, and sends the response message back to the 
NSP/PNSP that requests the service. The protocol used in this prototype is the 
Network-to-Network Interface defined in this proposal. . 
UNI Protocol Handler 

15 The UNI Protocol Handler passes the bandwidth and QoS related parameters 

via the ACS to a Routing Gateway associated with a subscriber. Because the Routing 
Gateway obtains its provisioning parameters from the ACS with a soon to be industry 
standard interface (WAN-Side DSL Configuration specification), this same interface 
may be used to communicate bandwidth and QoS information to the RG. 

20 DSL Service Manager - - — - .il.^u.iv...:.- — . ... 

The DSL Service Manager behaves as a service broker that provides one or 
more of the following functions: allows ASP/NSP/PNSP to set and query bandwidth 
and QoS data associated with a PPP session, and to create, change, and delete 
application flow control record associated with each individual application; interacts 

25 with BRAS to pass bandwidth and QoS related data and policies for prioritizing, 

shaping, and policing subscriber's traffic flow either associated with a PPP session or 
an individual application flow; and/or communicates with ACS to pass bandwidth and 
QoS related data and polices to a specified Routing gateway working together with 
BRAS for prioritizing, shaping, and policing the subscriber's traffic flow at the access 

30 network. 

DSL Session Data Store 

This is the Master Database maintaining the DSL data model described in 
section 4.3. It stores all the bandwidth and QoS related data and policies that can be 
queried, modified, created, and deleted by the ASP/NSP/PNSP through the ANI/NNI 

35 interface. The following records are maintained in the DSL Session Data Store in 

accordance with some embodiments of the present invention: a DSL Line Record; an 
NSP PPP Session Record; a Personal NSP PPP Session Record; an ASP PPP Session 
Record; and/or an application Flow Control Record. 
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5 This master copy is replicated in the BRAS and ACS network elements with 

appropriate data records. The BRAS copy of the data may include the following 
records in accordance with some embodiments of the present invention: an NSP PPP 
Session Record; a personal NSP PPP Session Record; an ASP PPP Session Record; 
and/or an Application Flow Control Record. 
1 0 The ACS network element may include a replica of the following records in 

accordance with some embodiments of the present invention: an NSP PPP Session 
Record; a personal NSP PPP Session Record; an ASP PPP Session Record; and/or an 
Application Flow Control Record. 
DSL Service API 

1 5 This service creation API is used by the ASP/NSP for creating their bandwidth 

and QoS "aware" applications. This API directly maps the ANI/NNI protocol defined 
in this proposal into procedures, methods, and/or other software embodiments, for 
- example, to facilitate application programming. 

20 Provisioning Interface ~- — 

This is a GUI based interface to allow the DSL Service Provider to provision 
the bandwidth and QoS settings for each individual subscriber based on subscriber 
telephone number, and provision the ASP/NSP that have a business arrangement with 
the DSL service provider. The data-model for support of the provisioning has been 

25 defined herein. 

6.4.2 DSL Service Messaging Flow 

This section provides several service scenarios to demonstrate how the messaging 
interface may be used by an ASP application in accordance with some embodiments of the 
present invention. 

30 

Service Provider Authentication Scenario Messaging Flow 

FIG. 14 illustrates the messaging flow for the application authentication 
scenario in accordance with some embodiments of the present invention. 
(1) EstablishServiceSessionRequest (SP_ID, SP_Credentials) 
35 This message is sent from the ASP/NSP to the DSLNetwork as a request for 

establishing a communication session. The ASP/NSP needs to be authenticated by 
the Regional/Access Network before any network service can be provided. 
Processing Steps: 
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5 a) ANI/NNI Protocol Handler receives the request message and passes the request to 
DSL Service Manager 

b) DSL Service Manager finds the corresponding Service Provider Record by 

querying DSL Session Data Store based on the SP_ID 

c) DSL Service Manager validates the SP_Credentials. A result of authentication is 
1 0 sent back to the ASP/N SP via ANI/NNI Protocol Handler. 

If the authentication is passed, a valid Authorization code is sent back. Otherwise, 
an invalid Authorization code is returned. 

(2) EstablishServiceSessionResponse (Authorization, Return_Code) 

15 This message is sent from Regional/Access Network to ASP/NSP as a 

response forthe service session establishment request. 

(3) TerminateServiceSessionRequest (SP_ID, Authorization) 

This message is sent from the ASP/NSP to the DSL Network as a request for 
terminating the -communication session. 

a) ANI/NNI Protocol Handler receives the request message and passes the request to 
DSL Service Manager. 

b) DSL Service Manager finds the corresponding communication session, terminates 
the session, and release all. the session related resources. 

c) DSL Service manager sends a result back to the ASP/NSP via ANI/NNI Protocol 
Handler. 

(4) TerminateServiceSessionResponse (SP_ID, Return_Code) 

This message is sent from Regional/Access Network to ASP/NSP as a response for 
30 the service session termination request. 

Application Level Bandwidth and OoS Query Scenario Messaging Flow 

FIG. 15 illustrates the messaging flow for the application level bandwidth and 

QoS query scenario in accordance with some embodiments of the present invention. 
35 (1) Query AppFlowControlRequest (Authorization, DSL_Line_ID, SP_ID, 
Flow_Classifer) 

This message is sent from the ASP to the DSLNetwork as a request for 
inquiring the bandwidth and QoS information associated with the specified DSL line. 
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Processing Steps: 

a) ANI Protocol Handler receives the request message and passes the request to DSL 

Service Manager 

b) DSL Service Manager finds the corresponding DSL Line Record, ASP PPP 

Session Record, and Application Flow Record(s) to collect the requested 
information. 

c) DSL Service Manager sends the collected bandwidth and QoS info back to the ASP 

via ANI Protocol Handler. 

(2) Query AppFlowControlResponse (DSLJLineJU), FlowClassifier, 
Flow JPriority, Flow_Bandwidth, Return_Code) 

This message is sent from Regional/Access Network to ASP as a response for 
inquiring the bandwidth and QoS info request. 

Application Level Bandwidth and QoS Modification Scenario Messaging Flow 

FIG. 16 illustrates the messaging flow for the application level bandwidth and 

QoS query modification scenario in accordance with some embodiments of the 

present invention. _ 

(1) ChangeAppFlowControlRequest (Authorization, DSL_Line^ID, SP_ID, 
Flow_Classifier, Flow_Priority, Flow_Bandwidth) 
This message is sent from the ASP to the Regional/ Access Network as a 

request for changing the bandwidth and QoS data associated with the specified DSL 

line. 

Processing Steps: 

a) ANI Protocol Handler receives the request message and passes the request to DSL 
Service Manager 

b) DSL Service Manager validates the authorization code based on corresponding 

Service Provider record, finds the corresponding DSL Line Record, ASP PPP 
Session Record, and Application Flow Record(s) to set the bandwidth and 
QoS data as requested by the ASP. 

c) DSL Service Manager communicates with BRAS Adapter for passing related 

bandwidth and QoS data to BRAS. 
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5 d) BRAS Adapter communicates with BRAS for setting the data in BRAS own data 
repository. 

e) DSL Service Manager notifies RG (via ACS) of new bandwidth and QoS info 

becoming available by sending the message of 

UpdateAppFlowControlInfo(DSL JLineJED, SP_ID, Flow_Classifier, 
10 Flow_Priority, Flow_Bandwidth) through UNI Protocol Handler. 

f) UNI Protocol Handler passes the new bandwidth and QoS data to a specified RG 

via ACS. 

g) ACS sends a response message back to UNI Protocol Handler to confirm the data 

is received. 

15 h) UNI Protocol Handler sends the message 

UpdateAppFlowControL\ck(DSL_Line_ID, SP_ID) back to DSL Service 
Manager as a response, 
i) DSL Service Manager sends the response message back to ASP via ANI Protocol 
Handler. 

20 j) ACS notifies the specified RG~of the availability of new bandwidth/QoS data via 
WAN-Side DSL Config Interface, 
k) The specified RG receives notification and downloads the new data from ACS. 

(2) ChangeAppFlowControlResponse (DSLvLine_ID, Return_Code) 

25 This message is sent from Regional/Access Network to ASP as a response for 

setting the bandwidth and QoS request. 

Application Flow Control Record Creation Scenario Messaging Flow 

FIG. 17 illustrates the messaging flow for the application flow control record 
30 creation scenario in accordance with some embodiments of the present invention. 
(1) CreateAppFlowControlRequest (Authorization, DSL JLine_ID, SP_ID, 
Flow_Classifier, Flow_Priority, Flow_Bandwidth) 

This message is sent from the ASP to the Regional/Access Network as a 
request for creating an Application Flow Control Record for a specified subscriber. 
35 Processing Steps: 

a) ANI Protocol Handler receives the request message and passes the request to DSL 
Service Manager 
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b) DSL Service Manager validates the authorization code based on corresponding 

Service Provider record, finds the corresponding DSL Line Record, ASP PPP 
Session Record, and then creates and sets an Application Flow Control Record 
as requested by the ASP. 

c) DSL Service Manager communicates with BRAS Adapter for passing related 

bandwidth and QoS data to BRAS. 

d) BRAS Adapter communicates with BRAS for setting the data in BRAS own data 

repository. 

e) DSL Service Manager notifies RG of new bandwidth and QoS becoming available 

by sending the message of UpdateAppFlowControlInfo(DSL_Line_ID, 
SP_ID, Flow_Classifier, FlowJPriority, Flow_Bandwidth) via UNI 
Protocol Handler. 

f) UNI Protocol Handler passes the new bandwidth and QoS data to a specified RG 

via ACS. 

g) ACS sends a response message back to UNI Protocol Handler to confirm the data 

is received. - . ..." . z;.u;:- - ^ 

h) UNI Protocol Handler sends the message 

UpdateAppFlowControlAck(DSL_Line__ID, SP_ID) back to DSL Service 
Manager as a response. 

i) DSL Service Manager sends the response message >ack to ASP^yiaiANLPrptocol 

Handler. 

j) ACS notifies the specified RG of the availability of new bandwidth/QoS data via 

WAN-Side DSL Config Interface, 
k) The specified RG receives notification and downloads the new data from ACS. 

(2) CreateAppFlowControlResponse (DSL_Line_ID, ReturnCode) 

This message is sent from DSL Network to ASP as a response for creating the 
application flow control record request. 

Application Flow Control Record Deletion Scenario Messaging Flow 

FIG. 18 illustrates the messaging flow for the application flow control record 

deletion scenario in accordance with some embodiments of the present invention. 

(1) DeleteAppFlowControlRecordRequest (Authorization, DSL_Line_ID, SP_ID, 
Flow_Classifier) 
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5 This message is sent from the ASP to the DSLNetwork as a request for 

deleting an Application Flow Control Record for a specified application. 
Processing Steps: 

a) ANI Protocol Handler receives the request message and passes the request to DSL 
Service Manager 

10 b) DSL Service Manager finds the corresponding DSL Line Record and associated the 
ASP PPP Session Record. Delete the App Flow Control Record based on the 
Flow_Classifier. 

c) DSL Service Manager sends a response back to ASP as a confirmation. 

15 (2) DeleteAppFlowControlRecordResponse (DSL_Line_ID, Return_Code) 

This message is sent from Regional/ Access Network to ASP as a response for 
deletion of App Flow Control Record request. 

NSP PPP Session Level Bandwidth and QoS Modification Scenario Messaging Flow 
20 .. FIG. 19 illustrates the messaging flow for the PPP session level bandwidth „• 

and QoS modification scenario in accordance with some embodiments of the present 

invention. ..-....„.„■ * 

(1) ChangeSessionBandwidthRequest (Authorization, DSL_Line_ID, SP_ID, 

Session_Classifier, Session_Priority, SessionJSandwidth) — . ^.rcs^r*-- 
25 This message is sent from the NSP to the Regional/ Access Network as a 

request for changing the PPP session level of bandwidth and QoS data associated with 

the specified DSL line. 

Processing Steps: 

a) NNI Protocol Handler receives the request message and passes the request to DSL 
30 Service Manager 

b) DSL Service Manager validates the authorization code based on the corresponding 

Service Provider record, finds the corresponding DSL Line Record, and the 
NSP/PNSP PPP Session Record to set the bandwidth and QoS data as 
requested by the NSP. 
35 c) DSL Service Manager communicates with BRAS Adapter for passing the 
bandwidth and QoS data to BRAS. 

d) BRAS Adapter communicates with BRAS for setting the data in BRAS own data 

repository. 
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5 e) DSL Service Manager notifies RG of new bandwidth and QoS being available by 
sending a notification to NNI Protocol Handler. 

f) NNI Protocol Handler passes the new bandwidth and QoS data associated with a 

specified RG to ACS by sending the following message to ACS. 
UpdateSessionBandwidthinfo(DSL_Line_ID, SP_ID, Session_Classifier, 
10 Session^Priority, Session_Bandwidth). 

g) ACS sends a response message back to NNI Protocol Handler to confirm the data 

is received by sending the following message. 
UpdateSessionBandwidthAck(DSL JJneJU), SP_ID) 

h) UNI Protocol Handler passes the acknowledgement back to DSL Service Manager 
15 as a response. 

i) DSL Service Manager sends the following response message back to NSP via NNI 

Protocol Handler. 

ChangeSessionBandwidthResponse(DSLJLine_ID, Return_Code) 

j) ACS notifies the specified RG of the availability of new bandwidth/QoS data via 
20 WAN-Side DSL Config Interface. . . . . 

k) The specified RG receives notification and downloads the new bandwidth and QoS 
data from ACS. 

(2) ChangeSessionBandwidthResponse (DSL_Line_ID, Return_Code) 

25 This message is sent from Regional/Access Network to NSP as a response for 

changing the PPP level of the bandwidth and QoS request. 

ASP/PPP Session Level Bandwidth and QoS Query Scenario Messaging Flow 

FIG. 20 illustrates the messaging flow for the PPP session level bandwidth and 
30 QoS query scenario in accordance with some embodiments of the present invention. 

(1) QuerySessionBandwidthRequest (Authorization, DSL_Line__ID, 
SP_ID) 

This message is sent from the ASP/NSP to the Regional/Access Network as a 
request for inquiring the bandwidth and QoS information associated with the 
35 specified DSL line. 
Processing Steps: 
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5 a) ANI/NNI Protocol Handler receives the request message and passes the request to 
DSL Service Manager 

b) DSL Service Manager finds the corresponding DSL Line Record and the ASP/NSP 

PPP Session Record to collect the requested information. 

c) DSL Service Manager sends the collected bandwidth and QoS info at PPP session 
10 level back to the ASP/NSP via ANI/NNI Protocol Handler. 

(2) QuerySessionBandwidthResponse (DSL_Line_ID, Session_Classifier, 
Session JPriority, Session JBandwidth, Return_Code) 
This message is sent from Regional/ Access Network to ASP/NSP as a 
response for inquiring the bandwidth and QoS info request. 

15 

7, Future Capabilities of the Application Framework 

Exemplary embodiments of the invention have been described above with 
respect to an Application Framework comprising a reference data model and an 
interface specification defined for specific transport flows related to QoS and 

20 bandwidth capabilities. This Application Framework may be expanded, in .. ..; . . 
accordance with some embodiments of the present invention to support other services 
that link network services, telecommunications information technology, and 
customers including, for example: registration - enables the ASP to register 
services/applications with the Regional/Access Network; discovery - enables the .-. 

25 Subscriber to discover services/applications within the Regional/Access Network; 
subscription - enables the ASP to manage and maintain subscriber accounts; 
management - for validation of subscribers and related services/applications; session - 
enables the xSP to manage and maintain session establishment, Management: session 
control, and session teardown for subscriber access to services/applications; 

30 authentication - enables the xSP to validate the user/subscriber for network access and 
services/applications access - who are you?; authorization - enables the xSP to 
validate the user/subscriber for network access and services/applications access - what 
permissions do you have?; profile - enables the xSP to manage and maintain 
user/subscriber profile data; identify - enables the xSP to manage and maintain user 

35 preferences, profiles, identity data; presence - enables the xSP to know and maintain 
awareness of the current existence of the subscriber; notification - enables the xSP to 
notify the subscriber of related services/applications information; and/or billing - 
enables the xSP to capture subscriber/user billing data for network usage and 
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5 services/applications usage for mediating a common billing record. These other 
capabilities may provide a host of centralized software services supporting a 
distributed network computing environment linking users/subscribers to their desired 
services and applications. 
8. Example Use Scenario - Turbo Button 

10 A source of potential frustration for users of data services is that data rates 

supported by the network (e.g., 1 .5 Mb/s downstream and 256 Kb/s upstream) are 
often not properly matched with application requirements. Even with the higher 
speeds afforded with DSL access, users of many applications (e.g., content download 
such as large MS Office service packs or movie trailers, and on-line gaming) may be 

1 5 interested in using a service that would provide an even higher access speed at the 
times they need it most by invoking a "Turbo Button" service. The higher access 
speed limit is achieved via a service profile change that eliminates or lessens 
artificially imposed limits on the achievable speed in the user's PPP session. This 
section shows how the DSL Application Framework can support such a service, in 

20 accordance with some embodiments of the present- invention, starting with the 
reference model shown in FIG. 21. 

Many implementations of a Turbo Button service are possible in accordance 
with various embodiments of the present invention. For the purposes of this section, 

- . . we will work with a fairly simple implementation in which the service is provisioned 

25 by an NSP called myNSP.com. The user requests the turbo button service at the 
community NSP's website during a browsing session at normal speed. Note that 
other ordering mechanisms are possible including mechanisms that are separate from 
the DSL session, e.g., using a telephone or a mass-distributed CD. 

As mentioned above in certain embodiments of the present invention, the 

30 service is implemented via provisioning rather than by using real-time signaling. 
Under this assumption, a provisioning cycle is initiated after the user invokes the 
service and the provisioning completes before the effect is seen. Another result of 
this assumption is that the effect of the user's service invocation is permanent, i.e., 
once turbo speed in place, it lasts until the user cancels the service and another 

35 provisioning cycle occurs to reinstate the default service parameters. Real-time 
signaling may be needed to support a service that supports on-demand,. brief turbo 
sessions on an as needed basis. 
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5 Once the user requests the turbo service, the NSP queries the Regional/Access 

network to find out what turbo options can be presented to the user. The NSP may map 
the available upgrades to marketing categories (e.g., fast, faster, wickedly fast). The user 
selects one of the options, and the NSP requests the profile from the Regional/Access 
network that supports the requested speed. The Regional/Access network in turn pushes 
1 0 new policy (e.g. , classifiers, rate limiters, priority) into the user's RG that will support the 
higher speed. It is important to note that the service is still "Best Effort," i.e., there is no 
assumption of a QoS guarantee at this time. A version of turbo button service with QoS 
support may be implemented in accordance with other embodiments of the present 
invention. 

1 5 We will assume that the NSP authenticates its own users for services such as 

Turbo Button. A centralized authentication service (as well as other ancillary services 
such as billing and presence functionality) could be implemented in the Regional/Access 
network on behalf of NSPs and ASPs in accordance with additional embodiments of the 
present invention. In a typical business model, the NSP might bill the user for usage of the 

.;:.„ _ 20 turbo button service. In turn, the DSL network provider would bill the NSP for carrying 

traffic across the Regional/Access network at turbo speeds. 

Turbo Button Scenario Description 
: FIG. 22 illustrates an example of the sequence of events occurring with using 

25 the Turbo Button Service to access sites via a network service provider called 
"myNSP.com." For simplicity of illustration, the details of the Regional/Access 
network (DSL Service Manager, UNI and ANI protocol handlers, ACS, BRAS, etc.) 
are not shown - the expanded flows were shown in Section 6.4. The step numbers 
shown in the figure correspond with the list provided below. 

30 

1 . The user clicks an advertisement to reach the NSP's Turbo Button subscription 
menu. 

2. The NSP host authenticates itself with the Regional/Access network in order to be 
able to access the customer profile it wants to update. 

35 3. Once authenticated, the NSP host then queries the Regional/Access network 

for available options for the users access session connection. It uses the 
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response to this query to put together a set of options for presentation to the 
customer. 

4. The user selects one of the options. 

5. The NSP requests the Regional/Access network to change the session bandwidth 
associated with the access session. A notification may be sent to the user 
indicating that the turbo button provisioning is under way and that turbo speed will 
be available later that day (for example). 

6. Using Update Session Bandwidth messaging, the Regional/Access network 
pushes new policy to the RG that will support the turbo speed. 

7. Once the new policy is in place, the user is able to enjoy turbo speed access to 
sites served by the NSP. Note that all users connected to the access session 
{i.e., other PC users on the household LAN) would also enjoy the benefits of 
the turbo button service. 

8. Later, the user decides to cancel turbo button service. 

9. Steps 5 and 6 are repeated with the profile and policy put in place being those 
needed for default access session speeds. 

10. The network has returned to its previous state and the user's PPP session is no 
longer turbo'd. 

9. Example Use Scenario - Video Conferencing 

This section illustrates how the DSL Application Framework can support a 
videoconference service in accordance with some embodiments of the present 
invention. The videoconferencing model used is a SIP-driven service implemented by 
an ASP with a centralized control/mixing conference server. This is the tightly 
coupled model being developed by an IETF Sipping WG design team that uses four 
logical entities: focus, conference state notification service, conference policy server 
element, and stream mixers. There are several ways that these entities can be spread 
over the available network segments. For example, the ASP and the Regional/Access 
network can each implement a subset of the entities; for example, the ASP can implement 
the stream mixing while the rest of the logical entities are implemented in the 
Regional/Access network. Such a division may be feasible from a technical perspective, 
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5 but the additional exposed interfaces may require standardization or bilateral agreement. 
There might not be much of a business case for such a model because there is little 
incentive for either the ASP or Regional/Access network to give up part of the service 
offering. 

Furthermore, all of the entities can be implemented in the regional/ Access 
10 network. This option offers some simplicity from the Regional/ Access network 

provider's perspective because no ASP is involved. This would probably 
balanced, however, by the network provider's need to decouple the 
videoconference service offering from the general DSL networking aspects. 
Finally, the ASP can implement all of the logical entities while the 
15 Regional/Access network provider concentrates on the transport issues. This 

approach is adopted for the rest of this section — the ASP handles all of the mixing as 
well as the application layer control. A reference diagram for the service with three 
users is shown in FIG. 23. 

From the user's perspective, the videoconferencing service has the following 
20 capabilities in accordance with some embodiments of the present invention: 

Creation/ Activation: the user can interact with the ASP and either request a reserved 
conference (without pre-designated participants) or activate a previously reserved 
conference; Termination: the conference ends at a pre-designated time; Adding 
Participants: All users are designated in advance; Dropping Parties: Although 
25 individual parties may stop participation in the conference, the resources in the 

network supporting their connections remain in place; and/or Stream Mixing: Basic 
audio and video mixing are provided. Each participant receives all of the other 
participants' audio and receives video from the participant with the loudest current 
audio. 

30 Assumptions regarding the service are as follows: the ASP that offers the 

videoconference service will host the MCU; the ASP's MCU will support the ASP's 
subscribers in all ASP networks for which that ASP is participating; videoconference 
client software compatible with an ASP's videoconference service is resident on all 
participant PCs; users that are not subscribed to the ASP's videoconference service will 

35 not be supported; DHCP leases do not expire; SIP Application Level Gateway (ALG) 
functions for handling NAT traversal are provided in the RG; the ASP providing the 
videoconference service maintains a common address repository or locator for its 
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5 subscribers. ASP's may be unwilling to share or store their subscriber information in a 
network database; mechanisms are in place to support application level communication 
between two ASP networks (see the dotted line shown); the ALG functions in the RG vise 
DiffServ Code Points (DSCP) from the voice and video streams and the port information 
pushed to it through the ACS profile to map audio and video flows to ports that are known 

10 to the BRAS for reclassification. A simpler approach may be to classify packets coming 
from the videoconference client based on packet type and protocol ID but that would mean 
the audio, and video RTP streams could not be distinguished by the classifier and would 
have to share the same priority; the DSCPs used by the videoconference clients are 
standardized; and/or by its nature RTP is a unidirectional stream, but RTCP is bi- 

1 5 directional. Each pair of RTP and RTCP UDP streams defines a channel. To simplify the 
presentation, only one direction of the RTP stream is shown for audio and data and only 
one control stream is shown. Typical SIP and H.323 videoconference implementations 
may require additional data and control streams to complete fully bi-directional data flows 
for all participants 

20 . At least two workable, business models can support this videoconferencing . 

service. In the simplest model, the videoconference ASP arranges for all potential 
conference participants to have the necessary policies in place to support the service. 
Once this infrastructure is provisioned, any subset of the participants can hold a 
videoconference at any time, A^slightly more complex model has some advantages 

25 for demonstration purposes - in this model, the videoconference ASP makes the 

necessary changes needed in the network to support a particular videoconference (and 
only the participants for that conference receive upgraded profiles to support their 
session). This model, which is used in this section, does not require that the policy be 
in place at all times, but may require a window (perhaps 24 hours) during which the 

30 provisioning changes are made. 

A number of billing models are possible. In some embodiments, the ASP bills 
(flat rate, usage, etc.) videoconference subscribers for their service. The 
Regional/Access network provider bills the ASP for hosting the service on the ASP 
network and for the usage of the Regional/Access network. Note that additional 

35 opportunities for the business model are possible for offering centralized billing, 
authentication, and presence capabilities to videoconference ASPs. 

The static provisioning model imposes some restrictions on videoconferencing 
service models. Reservations are made well in advance to allow the flow-through 
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5 provisioning to occur before the start of the conference. The reservation window thus 
needs to close before the start of the conference, for example 24 hours prior. No real- 
time adjustment of the schedule (such as early teardown because the participants 
finished early) is possible. The only way to update the participant list is for the user 
to request a replacement conference before the reservation window closes. 

10 Despite the use of the static provisioning model, the ability to map a particular 

conference's flows to a classifier still makes it possible to offer reasonable service 
features. The user may be able to set up multiple conference calls with different sets 
of people and with different QoS and bandwidth requirements (for example, a reduced 
frame rate may be desired for a conference a day after the conference in this example 

1 5 because several BRI users will be on the call). Without the mapping between the 
flows and the classifier, the user may have been able to have only one outstanding 
conference request. In addition, the user may be able to modify the arrangements for 
a particular conference (e.g., if the participant roster or start/end times change) 
provided that the reservation window (24 hour notice) has not closed. 

20 A goal of this section is to demonstrate l^at the Framework and Interface and 

Data Model are sufficient to support this basic videoconference service. After 
discussing the individual streams needed for videoconferencing, flows for setting up 
and tearing down videoconferencing flows in accordance with some embodiments of 
the present invention are presented. At the end t of thi|>section, the network model is 

25 expanded to include the DSL network's entities and further exercise the data model 
and messages that have been defined. 
Videoconferencing Scenario Descriptions 

The following sequence of events may occur in the process of registering for 
the ASP videoconference service, reserving a particular conference, and tearing it 

30 down once the conference is over. Assume that three users A, B, and C will be 

involved in the videoconference and that A will be the originator. For simplicity, the 
details of the Regional/Access network (DSL Service Manager, UNI and ANI 
protocol handlers, ACS, BRAS, etc.) are not shown - the expanded flows have been 
shown in Section 6.4. The step numbers shown in FIG. 24 and 25 correspond with 

35 the list provided below: 

1 . Assume that Users A, B, and C already have established PPP sessions between 
their RG's and the DSL network provider. 
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2. On the videoconference ASP website, User A registers to be able to set up 
videoconferences by setting up their user profile, billing options, etc. 

3 . User A decides to hold a videoconference with Users B and C on Tuesday 3 :00- 
4:00 and arranges this with the videoconference ASP. 

4. The ASP establishes a service sessions with the Regional/Access network and 
is authenticated. 

5. The ASP sends application flow control requests to the Regional/Access 
network requesting changes to support the videoconference. 

6. The Regional/Access network pushes new application flow policies to the 
BRAS, ACS, and RG's A, B, and C that are specific to the videoconference 
application. The videoconference stream facilities are now available. 

7. The videoconference starts at 3:00 on Tuesday (note that the flow has now 
moved). Inside the control streams, the videoconference ASP uses SIP to 
establish the necessary conference legs to users A, B, and C. The streams 
from the users are placed appropriately in the queues by the classifiers, are 
mixed by the videoconference ASP, and appropriately mixed streams are 
distributed to the participants. 

8. At 4:00 on Tuesday, the conference is scheduled to end. The videoconference 
ASP releases its internal resources for the mixers and conference control, 
sends SIP BYE messages through the control stream to clear the SIP dialogs 
with the users, and sends a billing record so that the appropriate charging takes 
place. 

9. The videoconference ASP establishes a service session with the DSL network 
(if necessary) and is authenticated. 

10. The videoconference ASP requests deletion of the application flow control 
records that supported the videoconference. 

The Regional/Access network deletes the policy for the bandwidth and QoS at the 
BRAS, ACS, and RG's for users A, B, and C. The network has now been returned to 
its default state. 

Flow Classification for Video Conferencing 
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5 The videoconference service may require three streams to carry audio, video, 

and signaling/control as shown in FIGS. 24 - 27. The flows referred to using a "+" 
sign in FIG. 27 may be set up dynamically at the VC client and the DSCP may be 
assigned for the audio and video streams. The ALG/NAT maps of the 10.X.X.X ports 
to the corresponding IP address and ports for audio and video specified in the ACS 
1 0 profile based on the DSCP set by the VC client. This may ensure that the RG, BRAS 
and ASP videoconference MCU maintain consistent port information with regard to 
the various flows. 

The signaling/control stream is used at the application layer for purposes, such 
as floor control and other needs, that are transparent to the Regional/ Access network 

1 5 provider. Assume that audio and control packets need to travel with high priority and 
thus are placed into the Expedited Forwarding queue at the RG. Video packets have 
medium priority and hence will be placed into the Assured Forwarding queue at the 
RG. The videoconference service does not cause the user to emit any low priority 
packets that we are aware of; thus, the RG will not need to place any packets into the 

20 Best Effort queue. - : " 

A goal is to demonstrate that it is possible for the ASP to push packet classifier 
information into the DSL network at conference reservation time so as to configure 
the DSL network for proper placement of packets from the three streams into the 
appropriate queues as mentioned above. At the time that a videoconference is- .;: 

25 reserved (to occur in this case 3:00-4:00 the next day), the user needs to get a 

conference identifier/PIN from the videoconference ASP. The user will use this 
conference identifier to get into the correct conference the next day, and will give the 
conference id to the other participants for the same purpose. For the purposes of this 
section, assume that this conference identifier does not need to show up in the data 

30 model because it is strictly between the users and the ASP and somehow transferred 
transparently to the DSL network provider. 

The ASP needs to set up bandwidth and priority for the three streams (control, 
video, and audio) that are needed between each user and the ASP using a Create 
Application Flow Control Request message. One benefit of looking at 

35 videoconference as a service example is to better understand how the various flows, 
would be set up and managed through NATs and firewalls and still have those flows 
appropriately classified throughout. Many protocols establish connections on well- 
known ports that spawn data flows on ephemeral ports (i.e., dynamically spawned and 
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5 assigned to a given multimedia call after the initial handshakes). The problem of 
firewall and NAT traversal is a complex one due, in part, to the large number of 
different scenarios and the multitude of different solutions to solve them. 

For this example, it is assumed that the RG has an ALG function for the 
support of SIP. Further it is assumed that there is a "trusted" relationship between the 

10 ASP and the Regional/Access network and the use of DSCP markings of packets can 
be used as part of the classification process. 

Referring to FIG. 24, information that is used for setting up and classifying the 
flows required for a videoconference in accordance with some embodiments of the present 
invention is illustrated. First, during the initial setup, user A registers all participants and 

1 5 specifies the start time and end times, etc.. The ASP reserves IP addresses for the 
conference on its platform and updates each participant's RG by issuing a 
createAppFlowReq request to the Regional access network. The BRAS uses the IP 
addresses specified by ASPi for reclassifying traffic to ASPi and will use the IP of the RG 
and the DSCP for reclassifying traffic en route to the videoconference client. The profile 

20 that gets pushed to. each participant will contain ASPi ' s IP addresses for control, audio, 

and video flows. When the start time for the videoconference approaches, each participant 
will activate their videoconference client on his or her PC and login to the reserved 
conference. 

Once ASPi receives the control message for call setup, it can refer to its table of 
25 reserved addresses to be used for the conference. Capability set negotiation occurs at this 
time (e.g., could be included in SDP component). The RG's ALG/NAT engine uses the 
DSCP and information from the ACS profile to determine which port it should assign to 
the RTP flows from the videoconference client. This may ensure consistency for the port 
information stored in the BRAS for reclassification. ASPi, the BRAS, and the RG should 
30 now know all addresses, priorities and shaping information. The videoconference client's 
RTP streams can begin pushing audio and video. 

10. Example Use Scenario - Gaming 

This section illustrates how the DSL Application Framework can support a gaming 
35 service in accordance with some embodiments of the present invention. Though there 
are many different models for game play and delivery, this section discusses a 
particular class of games known as "massively multi-player interactive" games. Such 
games are characterized by substantial numbers of players (greater than 1 0 and up to 
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5 the 1000s) and real time or near real-time interactions. Such games place significant 
demands on network and game server infrastructures. Other classes of games that are 
not discussed here include turn based games, single player (turn based or real time 
, interactive), and head to head interactive games. Though each of these classes 
represents a significant number of games available to users, their network 

10 requirements are not nearly as complex as those of multi-player interactive games. 
Gaming Service Overview 

Two basic topologies are used to support network gaming: point to point or 
client server. In client server topology, the player's workstation communicates with a 
central game server to which other players are also connected. In the point to point 

15 topology, each player communicates directly with each other player. A refinement of 
the client server topology, the hierarchical client server topology, provides the 
necessary infrastructure to support true massively multi-player environments. These 
topologies are depicted in FIG. 28. 

In the point to point topology, each gaming workstation must transmit its 

20 moves and state change information to each other gaming workstation. In addition, 
each workstation must maintain a consistent and synchronized image of the game 
universe for each player. As such the point to point topology requires significant 
computation power in the end user workstation and typically will not scale to 
supporting more than a number of users. - 

25 In both forms of the client server topology, the workstation and game server 

exchange information that is directly relevant only to a specific player. The client 
workstation is responsible for such tasks as managing user interactions, rendering, and 
audio feedback, while the server is responsible for maintaining a consistent view of 
the game universe and communicating changes to the view to player workstations. 

30 The difference between the two topologies is one of segmentation. In the hierarchical 
topology, a server is only responsible for maintaining the state of a portion of the 
universe. If a player connected to a particular server is interacting with a portion of 
the universe outside the scope of their immediate server, that server must coordinate 
with other servers in the network. This partitioning provides significantly more 

35 scalability than a simple client server topology. 

In addition to maintaining game universe state at communicating state changes 
to players, a gaming service may provide other auxiliary functions including the 
following: Session Management: manages active player lists, supports ability to invite 
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5 participants to join a game; presence and availability management: supports the 
ability of players to locate and determine if opponents are available for play; 
authentication: verify player identities and validate that players are using correctly 
licensed software on their workstation; interactive chat and bulletin board: provides a 
forum for discussion of gaming topics. Can also be used during game play to allow 

10 for intra-team communication; and/or content downloads: provides software update 
and new game delivery services: 

Basic game server functionality and auxiliary functions represent a gaming 
service that may be offered in an ASP model in accordance with some embodiments 
of the present invention. The game server and servers for auxiliary functions are 

1 5 connected to the ASP network. Client workstations access a game server or auxiliary 
function server through their ASP network connection. From the perspective of the 
DSL network, whether a gaming service implements a client/server or hierarchical 
client/server topology is not important. The DSL network is only involved in the 
transport of traffic between one or more game workstations and the game server to 

20 which they are connected. This service model is show in FIG, 29.. 
Traffic and Flow Characterization 

In a client/server multiplayer gaming service, the game server and player 
workstation communicate state change and play event information in real time. The 
: workstation informs the server of player triggered events including the following: . 

25 Player moves; Player takes a shot; Player changes rooms; and/or Player picks up an 
object. 

In a real-time game, the server reconciles these play event messages as they 
are received from each workstation or peer server. It then communicates state change 
information to each client workstation. These state change messages contain only 

30 information relevant to the particular player - only information about objects 
currently visible to the player is communicated. Examples of this information 
include: movement of other objects within the player's current view; hits made by the 
player; damage incurred by the player; death of the player or other players; and/or 
communication from the server or other players. Unfortunately, there does not appear 

35 to be a standard protocol for such communications; each gaming system seems to 

define its own methods of communication. The basic characteristics, however, seem 
to be similar. 
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5 While communication from the workstation to the server is typically event 

driven, server to workstation communication is often continuous. Servers often send 
state change messages in frames at a defined rate - 1 0 5 20, 30 frames per second. 
Frames tend to be significantly larger than voice or video frames. The total time 
required to send a user event, reconcile its impact on the game universe, and 

1 0 communicate state change back to the workstation may become the limiting factor in 
player reaction time. The longer the total time, the less reactive a player can be and 
the less interactive the gaming experience may become. 

Reconciliation time is driven by server capacity and load. Message delivery 
times are driven by network limitations. For many games, a total round trip "ping" 

15 time of 200-3 5 0ms is considered acceptable while 100ms is considered exceptional. 
Anything greater than 500ms may become very obvious to the player and is perceived 
as sluggishness. As latency increases it becomes more likely that players do not share 
a consistent view of the universe. 

In summary, game play related traffic can be characterized as follows: steady 

20 frame rate; large frame size (relative to. voice, or video); and/or latency sensitive 
Auxiliary services generally do not share these characteristics. They typically are 
similar or identical to traditional Internet Web based services and do not suffer from 
significant. impacts due to latency. 

The bandwidth requirement for play related traffic is generally lower than for 

25 video services, but the latency sensitivity of game play traffic typically necessitates 
better than best-effort treatment. Flows related to game play may be placed in an 
assured forwarding queue at a minimum. Auxiliary services may be handled on a best 
effort basis. Play related traffic and auxiliary service traffic are typically carried in 
different flows. 

30 Traffic within a game play flow may be further differentiated in accordance 

with additional embodiments of the present invention. For example, within the , 
context of a particular game certain events may be treated with higher priority than 
others. This may be supported by allowing the application to use and set multiple 
diffserv code-points. Such use, however, may only be permitted if there is a trusted 

35 relationship between the ASP gaming host and the transport network. 
Example Scenario Description 

The call flow for gaming is similar to Turbo button. The game provider needs 
to negotiate bandwidth profiles between the game server and the player workstation 
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5 for the purposes of game play traffic. The steps in this scenario are illustrated in 

FIGS. 30 and 31, in accordance with some embodiments of the invention, as follows: 

1 . Subscriber establishes PPP session between RG and DSL network provider. 

2. Subscriber accesses ASP gaming providers web site and registers for game 
play. 

10 3 . ASP gaming provider queries subscriber bandwidth profile and determines 

current profile to be insufficient for game play. 

4. ASP creates application bandwidth/QOS profile at Regional Access Network. 

5. ASP acknowledges subscription. 

6. Regional access network pushes new flow qualifier and bandwidth info for 
15 game service to routing gateway. 

7. Subscriber joins game using QOS enabled session. 

11. Application Flow Control Data 

Some embodiments of the present invention will now be discussed with 

20 respect to Figure 32'/ As discussed above, a regional/access network 1001 such as a 
digital subscriber line (DSL) network may be used to provide broadband data 
connectivity between one or more network service providers 1003b-c, application 
service providers 1005a-b, and one or more customer premises networks 1007. While 
connectivity between the regional/access network 1001 and a single customer 

25 premises network 1007 is illustrated in Figure 32, it will be understood that the 

regional/access network 1001 generally will support connectivity with many customer 
premises networks. 

A network interface device (NID) 1009 may provide an interface between 
local loop wires of the regional/access network (RAN) 1001 and the customer 

30 premises network 1007. On the customer side of the NID 1009, a routing gateway 
1011 (such as a DSL modem remote from the regional/access network 1001) may 
receive data from and transmit data to the regional/access network 1001. Moreover, 
multiple user devices 1015a-b (such as personal and/or laptop computers) may 
concurrently access the regional/access network 1001 through the routing gateway 

35 1011. More particularly, the NID 1009 may provide an interface between the routing 
gateway 1011 and a local loop providing voice and data connectivity to a main 
distribution frame (MDF) 1019 of a public switched telephone network (PSTN) so 
that data connectivity is provided as a digital subscriber line. It will be understood 
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5 that the operator of the regional/access network 1001 may also provide telephone 
voice and/or other data services. Telephone voice and/or other data services are not 
discussed herein or illustrated in Figure 32 for the sake of clarity. 

The access node 1021 may provide aggregation between an access portion of 
the network and a regional portion of the network, and may provide aggregation of 

1 0 data from multiple digital subscriber lines. The automated configuration server 

(ACS) 1023 may provide configuration information to routing gateways 1011 at the 
various customer premises networks 1007, and the UNI protocol handler 1024 may 
provide an interface between the service manager 1043 and the automated 
configuration server 1023. The regional/access network 1001 may also support 

15 legacy asynchronous transfer mode (ATM) network service providers (NSP) 1003a 
using one or more ATM transceiver(s) 1025 and/or ATM switches 1027. 

' n A concentrator 1029 such as a broadband remote access server (BRAS) may 
provide aggregation between the regional/access network 1001 and network service 
providers 1003b-c and application, service providers 1005a-b. The concentrator 1029 

20 and the routing gateway 1011 may provide control of session bandwidth and queuing 
priority for data transmitted by and received from the particular routing gateway 
1011. Moreover, the application flow control information for each session being 
conducted at a routing gateway 1011 may be stored at that routing gateway 1011. 
Accordingly, the concentrator 1029 and the routing gateway 1011 may implement 

25 appropriate bandwidth restrictions and/or queuing priorities for all data sessions being 
conducted between the two. As further shown in Figure 32, data from the network 
service providers 1003b-c and application service providers 1005a-b may be 
transported through an IP network 1033 to the RG 1011 via the RAN 1001, and the IP 
network 1033 may also transport data from the RAN 1001 to the network service 

30 providers 1003b-c and the application service providers 1005a-b. 

In addition, an application framework infrastructure 1041 provides data flow 
management for data sessions between routing gateways 1011 and network service 
providers 1003b-c and application service providers 1005a-b according to 
embodiments of the present invention. More particularly, a service manager 1043 

35 (such as a DSL service manager) may coordinate implementation of data flow 
characteristics for particular sessions between network service providers (NSPs), 
application service providers (ASPs), and routing gateways. As shown in Figure 32, 
communications between the service manager 1043 and application service providers 
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5 1005a-b may be provided by an application-to-network interface (ANI) protocol 
handler 1045. Communications between the service manager 1043 and network 
service providers 1003b-c may be provided by network-to-network interface (NNI) 
protocol handler 1047. Communications between the service manager 1043 and the 
concentrator 1029 may be provided through the concentrator adapter 1049. 

1 0 Communication between the service manager 1043 and the routing gateway 1011 

may be provided through the UNI protocol handler 1024, the automated configuration 
server 1023, the IP network 1033, the concentrator 1029, ATM switch 1027, access 
node 1021, MDF 1019, and network interface device 1009. 

As shown in Figure 32, the application framework infrastructure 1041 may 

15 include ANI protocol handler 1045, NNI protocol handler 1047, concentrator adapter 
1049, UNI protocol handler 1024, automated configuration server 1023, service 
manager 1043, session data store 1051, and provisioning interface 1053. As 
illustrated in Figure 32, functionality of the application framework infrastructure 1041 
may be implemented outside functional elements illustrated in the regional/access 

20 network 1001. In an alternative, functionality of some_or all of the elements of the 
application framework infrastructure 1041 may be implemented within one or more 
elements illustrated in the regional/access network 1001. For example, some or all of 
the elements of the application framework infrastructure 1041 may be implemented 
within the concentrator 1029. More particularly, some or all of the elements of the 

25 application framework infrastructure 1041 may be implemented as software 

components operating on a server providing functionality of the concentrator 1029. 
In addition or in an alternative, elements of the application framework infrastructure 
1041 may be implemented as software components operating in elements of the 
regional/access network 1001 other than the concentrator 1029, and/or operating in an 

30 additional element or elements (such as one or more additional servers) not included 
in the regional/access network 1001 illustrated in Figure 32. _ 

According to embodiments of the present invention, the regional access 
network 1001 may provide a data path for traffic flow between one or more routing 
gateways 1011 and one or more of legacy ATM 1003a, NSP's 1003b-c, and/or ASPs 

35 1005a-b. More particularly, a data path may be provided through IP network 1033, 
concentrator 1029, ATM 1027, access node 1021, and MDF 1019. Elements of the 
regional/access network 1001 and/or the application framework infrastructure 1041 
may also provide separate signaling paths. A signaling path between service manager 

76 



Attorney Docket No. 9400-50 

5 1043 and one or both of ASPs 1005a-b may be provided through the ANI protocol 
handler 1045, and IP network 1033. A signaling path between service manager 1043 
and NSP 1003b and/or NSP 1003c may be provided through NNI protocol handler 
1047, concentrator 1029, and IP network 1033. A signaling path between the service 
manager 1043 and concentrator 1029 may be provided through concentrator adapter 
10 1049 and IP network 1033. A signaling path between the service manager 1043 and 
the routing gateway may be provided through UNI protocol handler 1024, automated 
configuration server 1023, concentrator 1029, ATM 1027, access node 1021, and 
MDF1019. 

More particularly, the concentrator 1029 may be a broadband remote access 
15 server (BRAS), and a particular concentrator adapter 1049 may be used to provide an 
appropriate interface for a particular broadband remote access server. For example, 
the concentrator 1029 may be provided using a broadband remote access server such 
as a Shasta 5000 Broadband Service Node produced by Nortel Networks or a Juniper 
ERX-310 BRAS/edge router produced by Juniper Networks. Accordingly, the 
20 concentration adapter 1049 may be .modified to.pro vide, compatibility with different 
concentrators. 

While not separately illustrated in- FIG. 32, each of the routing gateway 1011, 
the application service providers 1005a-b, and the network service providers 1003b-c 
may include a transceiver(s) to transmit data to and receive data from the 

25 regional/access network 1001. In addition, the concentrator 1029 may also include a 
transceiver to transmit data to and receive data from the application service providers 
1005a-b and the network service providers 1003b-c. Similarly, the MDF 1019 and/or 
the access node 1021 may include a transceiver to transmit data to and/or receive data 
from routing gateways. 

30 Moreover, transmitters, receivers, and/or transceivers according to 

embodiments of the present invention may be wired and/or wireless. By way of 
example, transmitters, receivers, and/or transceivers according to embodiments of the 
present invention may be provided using circuit-switched networks, and/or packet- 
based networks and/or network elements, such as Internet Protocol (IP) networks and 

35 elements. In addition or in alternatives, transmitters, receivers, and/or transceivers 
according to embodiments of the present invention may be provided wirelessly, for 
example, using cellular communications, personal communications systems (PCS), 
WiFi, Ultrawideband, Bluetooth, and/or satellite communications. In addition or in 
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5 other alternatives, transmitters, receivers, and/or transceivers according to 

embodiments of the present invention may be provided in wireline environments such 
as in cable communications and/or power line communications. 

Information relating to data flow characteristics can be stored in the session 
data store 1051, and a provisioning interface 1053 may allow an operator of the 

10 regional/access network 1001 to provision bandwidth and Quality-of-Service settings 
for each individual subscriber. Accordingly, application flow control information for 
each session conducted at each routing gateway may be stored at the session data 
store 1051, and at the routing gateway 1011. Moreover, an application flow control 
record may be created by the service manager 1043 responsive to a request from one 

15 of the application service providers 1005a-b when a data session with a routing 
gateway is established with one of the application service providers, and the 
application flow control record may be deleted by the service manager 1043 
responsive to a request from one of the application service providers 1005a-b when 
the data session with the routing gateway is terminated. Operations of elements * 

20 illustrated in Figure 32 are discussed above in greater detail, for example, with respect 
to Figures 1-7 and 13-21, and/or at Sections 6.4, 6.4.1, and 6.4.2, and more 
particularly, at Section 6.4.2 "Application Flow Control Record Creation Scenario - 
Messaging Flow", and at Section 6.4.2 "Application Flow Control Record Deletion - 
Scenario Messaging Flow". - - - ■• - ^ 

25 According to particular embodiments of the present invention, a user at a user 

device 1015a may establish a data session using an application service provided by 
one of the application service providers 1005a-b over a data path established through 
the routing gateway 1011, the network interface device 1009, and the regional/access 
network 1001. For example, the application service provider 1005a may provide one 

30 or more of application services such as gaming, video on demand, and/or access to 
virtual private networks (VPNs) via IPsec and/or another Internet Protocol tunneling 
technique. The application service provider 1005a may initiate establishing a data 
session through the regional/access network 1001 and the routing gateway 1011 
responsive to a request received from the user device 1015a over the regional/access 

35 network 1001. When the data session is complete and/or when a termination request 
is received from the user device 1015a, the application service provider 1005a may 
initiate terminating the data session. 
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5 More particularly, the application service provider 1005a may initiate a data 

session with a user device through a particular routing gateway 1011 by generating an 
application flow control' record request (such as an AppFlowControlRequest as 
discussed above). The application flow control record request may include an 
identification of the service provider (such as a SP_ID as discussed above), an 

10 identification of the routing gateway (such as a DSLJLine_ID discussed above), and 
data flow characteristics for the application service being requested (such as a 
- Flow_Classifier, a Flow_Priority, and a Flow_Bandwidth discussed above). The 
application flow control record request may also include an authorization code 
(previously provided by the regional/access network 1001) that identifies the 

15 particular application service being established. 

The application flow control record request can be received at the ANI 
protocol handler 1045 and forwarded to the service manager 1043. If an authorization 
code is included in the request, the service manager 1043 may validate the application 
flow control record request using the authorization code, and create an application 

20 flow control record for the data session if the request is valid: In. an alternative, the. 
application flow control record may be created without requiring validation. More 
particularly, the application flow control record may be created by saving information 
from the application flow control record request at the session data store 1051. 

The application flow control record may include the data flow characteristics 

25 for the application data session, and the data flow control characteristics may include 
a bandwidth characterization (such as a Flow_Priority as discussed above) for the 
application service and a priority characterization (such as a Flow_Priority as 
discussed above) for the application service. The service manager 1043 may 
communicate the data flow characteristics for the application service and requesting 

30 routing gateway 1011 through the regional/access network 1001. For example, the 
service manager 1043 may communicate the data flow characteristics for the 
application service through the concentration adapter 1049 and the IP network 1033 to 
the concentrator 1029. The service manager 1043 may communicate the data flow 
characteristics for the application service to the routing gateway 1011 through the 

35 UNI protocol handler 1024, the automated configuration server 1023, the IP network 
1033, the concentrator 1029, the ATM 1027, the access node 1021, and the MDF 
1019. Accordingly, the data flow characteristics for the routing gateway 1011 
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5 requesting the application service may be stored at the session data store 1051 and at 
the requesting routing gateway 1011. 

The data flow characteristics for the session of the routing gateway 1011 using 
the application service provided by the application service provider 1005a may thus 
be saved as an application flow control record for the routing gateway 1011 at the 

10 session data store 1051 used by the service manager 1043. Moreover, the data flow 
characteristics can be forwarded to and saved at the routing gateway 1011, 
Accordingly, the data flow characteristics can be used at the concentrator 1029 and at 
the routing gateway 1011 when providing the data path between the routing gateway 
1011 and the application service provider 1005a to support a session of the routing 

1 5 gateway 1011 using the application service provided by the application service 

provider 1005a. More particularly, the data flow characteristics can be used by the 
concentrator 1029 and the routing gateway 1011 to police the flow of data of the 
session between the routing gateway 1011 and the application service provider 1005a 
according to the data flow characteristics provided by the application service provider 

20 for the session.- 

When the session between the application service provider 1005a and the 
routing gateway 1011 is over, the data flow characteristics saved at the session data 
store 1051 may be deleted. For example, the application service provider 1005a may 
determine that the session with the routing gateway 1011 is complete responsive to 

25 receiving a termination request from the routing gateway 1011, responsive to 
determining that a time out period has passed without communication from the 
routing gateway 1011, and/or responsive to determining that a session time limit has 
been exceeded. 

Once the application service provider 1005a determines that the session is 
30 complete, the application service provider 1005a may transmit a request to delete the 
data flow characteristics for the session, and the request may be received by the ANI 
protocol handler 1045 and passed to the service manager 1043. The service manager 
1043 may then delete the data flow characteristics saved at the session data store 1051 
for the session of the routing gateway 1011 using the application service provided by 
35 the application service provider 1005a, and the data path between the routing gateway 
1011 and the application service provider 1005a may be terminated to end the session 
of the routing gateway using the application service provider. 
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5 A data network may be operated between a routing gateway for a subscriber 

and an application service provider according to additional embodiments of the 
present invention illustrated in Figure 33. In particular, the data network may receive 
ah identification of the routing gateway, an identification of the application service 
provider, and data flow characteristics of an application service for a session of the 

10 routing gateway using the application service provided by the application service 
provider at block 2001. Responsive to receiving the information, the data flow 
characteristics .of the application service may be saved at block 2003, and the data 
flow characteristics may be forwarded to the routing gateway at block 2005. More 
particularly, the data flow characteristics may include a bandwidth characterization 

1 5 and a priority characterization for the application service. 

In addition, an authorization code may be received with the identification of 
the routing gateway, the identification of the application, and the data flow 
characteristics, and the authorization code may be validated at the network before 
saving the data flow characteristics. Moreover, saving the data flow control 

20 characteristics.may include creating an application flow control record for the routing 
gateway, and the data flow characteristics may be at first and second databases within 
the data network. Moreover, the first database may be associated with a concentrator 
of the data network, and the second database may be associated with a service 
manager of the data network. 

25 Receiving identifications and data flow characteristics at block 2001 may be 

preceded by receiving a request from a routing gateway for a session using the 
application service provided by the application service provider, and forwarding the 
request from the routing gateway to the application service provider. Once the data 
flow characteristics have been saved at the data network and forwarded to the routing 

30 gateway at blocks 2003 and 2005, an interconnection may be provided between the 
routing gateway and the application service provider in accordance with the data flow 
characteristics to support a session of the routing gateway of the subscriber using the 
application service provided by the application service provider. 

Once the data session between the routing gateway and the application service 

35 provider is complete so that the data path is no longer needed, the data flow 

characteristics saved at the data network for the session may be deleted, and the data 
path between the routing gateway and the application may be terminated. More 
particularly, a request may be received from the application service provider to delete 
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5 the data flow characteristics before deleting the data flow characteristics, and the data 
flow characteristics may be deleted responsive to the request from the application 
service provider to thereby terminate the data path and the data session. Operations 
relating to application flow control records are also discussed above with respect to 
Figures. 17 and 18. 

10 An application service provider may be operated to provide an application 

service over a data network to a routing gateway for a subscriber according to still 
additional embodiments of the present invention illustrated in Figure 34. As shown at 
block 3001 of Figure 34, the application service provider may transmit to the data 
network an identification of the routing gateway, an identification of the application 

15 service provider, and data flow characteristics of the application service for a session 
with the routing gateway using the application service. At block 3003, the application 
service may be provided over the data network and routing gateway in accordance 
with the data flow characteristics transmitted to the data network to support a data 
session of the application service provider with the routing gateway. 

20 More particularly, the routing gateway, may be coupled to the data network via 

a digital subscriber line, and the identification of the routing gateway may be a digital 
subscriber line identification. Moreover, the data flow characteristics of the 
application service may include a bandwidth characterization for the application 
service and a priority characterization for the application service. In addition, 

25 transmitting at block 3001 may also include transmitting an authorization code for the 
application service, and the application service provider may wait to receive a 
validation of the authorization code from the data network before providing the 
application service at block 3001. 

Transmitting at block 3001 may be performed responsive to receiving a 

30 request from the routing gateway for a session using the application service. When 
the data session providing the application service to the routing gateway is complete, 
the application service provider may transmit a request to the application service 
provider to delete the data flow characteristics for the session of the routing gateway 
using the application service, and the application service over the data network and 

35 routing gateway may be terminated. The data session may be terminated, for 

example, responsive to a request from the routing gateway, responsive to passing of a 
predetermined period of time without activity, and/or responsive to passing of a 
predetermined period of time allowed for a data session. 
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5 A routing gateway may be operated to provide subscriber use of an application 

service provided by an application service provider over a data network according to 
yet additional embodiments of the present invention illustrated in Figure 35. In 
particular, the routing gateway may receive data flow characteristics of the application 
service for a session of the routing gateway using the application service provided by 

10 the application service provider at block 4001. At block 4003, access to the 

application service may be provided over the data network in accordance with the 
data flow characteristics received from the data network to support a data session with 
the application service provider. 

More particularly, the routing gateway may be coupled to the data network via 

1 5 a digital subscriber line. Moreover, the data flow characteristics of the application 
service may include a bandwidth characterization for the application service and a 
priority characterization for the application service. In addition, receiving the data 
flow characteristics at block 4001 may be preceded by transmitting a request to the 
application service provider for a session using the application service provided by the 

20. . application service provider.. . *„ - _ .... . 

Many variations and modifications can be made to the preferred embodiments 
without substantially departing from the principles of the present invention. All such 
variations and modifications are intended to be included herein within the scope of the 
present invention, as set forth in the following claims. 

25 
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